On Tue, 5 Oct 2021 03:53:17 -0400
"Michael S. Tsirkin" wrote:
> > Wouldn't a call from transport code into virtio core
> > be more handy? What I have in mind is stuff like vhost-user and vdpa. My
> > understanding is, that for vhost setups where the config is outside qemu,
> > we probably need a
On Mon, 4 Oct 2021 05:07:13 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 04:23:23AM +0200, Halil Pasic wrote:
> > On Sat, 2 Oct 2021 14:13:37 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > > Anyone else have
On Mon, 4 Oct 2021 09:11:04 -0400
"Michael S. Tsirkin" wrote:
> > >> static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
> > >> {
> > >> #if defined(LEGACY_VIRTIO_IS_BIENDIAN)
> > >> return virtio_is_big_endian(vdev);
> > >> #elif defined(TARGET_WORDS_BIGENDIAN)
> > >> if
On Thu, 23 Sep 2021 16:28:11 +0200
Halil Pasic wrote:
> Can't we use some of the established constants instead of hard coding a
> qemu specific IOV_MAX?
>
> POSIX.1 seems to guarantee the availability of IOV_MAX in
> according to: https://man7.org/linux/man-pages/man2/readv.2.
constants instead of hard coding a
qemu specific IOV_MAX?
POSIX.1 seems to guarantee the availability of IOV_MAX in
according to: https://man7.org/linux/man-pages/man2/readv.2.html
and may have UIO_MAXIOV defined.
>
> Reported-by: Halil Pasic
> Cc: Hanna Reitz
> Cc: Kevin Wolf
&
On Thu, 23 Sep 2021 12:57:38 +0200
Paolo Bonzini wrote:
> On 22/09/21 21:51, Halil Pasic wrote:
> > We have figured out what is going on here. The problem seems to be
> > specific to linux aio, which seems to limit the size of the iovec to
> > 1024 (UIO_MAXIOV).
>
&g
On Mon, 6 Sep 2021 16:24:20 +0200
Halil Pasic wrote:
> On Fri, 25 Jun 2021 16:18:12 +0200
> Paolo Bonzini wrote:
>
> > bs->sg is only true for character devices, but block devices can also
> > be used with scsi-block and scsi-generic. Unfortunately BLKSECTGET
>
On Fri, 25 Jun 2021 16:18:12 +0200
Paolo Bonzini wrote:
> bs->sg is only true for character devices, but block devices can also
> be used with scsi-block and scsi-generic. Unfortunately BLKSECTGET
> returns bytes in an int for /dev/sgN devices, and sectors in a short
> for block devices, so
let's simply replace the PAGE_SIZE, PAGE_MASK
> and PAGE_SHIFT macro with their TARGET_* counterparts.
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/572
> Signed-off-by: Thomas Huth
Reviewed-by: Halil Pasic
On Mon, 30 Aug 2021 11:51:51 +0200
Christian Borntraeger wrote:
> On 27.08.21 12:50, Pierre Morel wrote:
> > Hello All,
> >
> >
> > This series presents a VIRTIO test device which receives data on its
> > input channel and sends back a simple checksum for the data it received
> > on its output
: expected(21) == received(0)
>
> Because we end up not injecting an operand program exception.
>
> Fixes: a54b8ac340c2 ("css: SCHIB measurement block origin must be aligned")
> Cc: Halil Pasic
> Cc: Cornelia Huck
> Cc: Christian Borntraeger
> Cc: Richard H
oes not trigger
> a subchannel status program check to the guest as it should.
>
> Let's test the return values of ccw_dstream_write[_buf] and
> ccw_dstream_read[_buf] and report it to the caller.
>
> Signed-off-by: Pierre Morel
Acked-by: Halil Pasic
I did not look into the whol
On Thu, 8 Apr 2021 11:02:32 +0200
Cornelia Huck wrote:
> On Wed, 7 Apr 2021 19:47:11 +0200
> Halil Pasic wrote:
>
> > So this begs the question, do we need this fixed for old releases as well?
> >
> > My answer is yes we do. Conny what do you think?
>
> Wh
On Tue, 6 Apr 2021 09:44:13 +0200
Pierre Morel wrote:
> ccw_dstream_read/write functions returned values are sometime
> not taking into account and reported back to the upper level
> of interpretation of CCW instructions.
The return values of ccw_dstream_write/read were intentionally ignored
On Wed, 7 Apr 2021 13:41:57 +0200
Pierre Morel wrote:
> > Here, however, I'm not sure. Returning a negative error here is fine,
> > but handle_payload_3270_write (not changed in this patch) seems to
> > match everything to -EIO. Shouldn't it just be propagated, and maybe 0
> > mapped to -EIO
On Thu, 25 Mar 2021 09:55:09 -0400
Matthew Rosato wrote:
> S390 PCI currently has no backup, add one. Add an additional backup
> for vfio-ccw and refresh the backup for vfio-ap.
>
> Signed-off-by: Matthew Rosato
Acked-by: Halil Pasic
that symlink based approach, if that is
what the community wants, but I would prefer this fixed as soon as
possible.
If you keep the authorship for all the patches, I would like to offer:
Reviewed-by: Halil Pasic
Tested-by: Halil Pasic
for all three patches. (If I'm going to be the author of
On Thu, 18 Mar 2021 12:36:48 +0100
Philippe Mathieu-Daudé wrote:
> > diff --git a/roms/SLOF b/roms/SLOF
> > index 33a7322de1..e18ddad851 16
> > --- a/roms/SLOF
> > +++ b/roms/SLOF
> > @@ -1 +1 @@
> > -Subproject commit 33a7322de13e9dca4b38851a345a58d37e7a441d
> > +Subproject commit
.html
Changelog v3 --> RFC:
* switch to the symlinks approach (Daniel)
* split s390x and common in separate patches (Eduardo)
Halil Pasic (2):
modules: introduce target specific modules
hw/s390x: modularize virtio-gpu-ccw
hw/s390x/meson.build | 8 +-
include/hw/s390x/cs
changes to what modules are available to what
targets. For the exploitation have look at 'hw/s390x: modularize
virtio-gpu-ccw'.
[1] https://mail.gnu.org/archive/html/qemu-s390x/2021-03/msg00206.html
Signed-off-by: Halil Pasic
Suggested-by: "Daniel P. Berrangé"
---
hw/s390x/m
enters did not like the
consequences of that.
Moving the interrupt related declarations to s390_flic.h was suggested
by Cornelia Huck.
Signed-off-by: Halil Pasic
---
hw/s390x/meson.build | 7 +++
include/hw/s390x/css.h | 7 ---
include/hw/s390x/s390_flic.h | 3 +++
target/s
On Tue, 9 Mar 2021 13:21:14 +
Daniel P. Berrangé wrote:
> > Well, yes, in a non-modular world this will work perfectly fine. We
> > only compile objects actually supported into the system emulator.
> >
> > With modular builds we have the situation that we have shared modules
> > which may
On Fri, 5 Mar 2021 16:46:03 -0500
Eduardo Habkost wrote:
> On Tue, Mar 02, 2021 at 06:35:44PM +0100, Halil Pasic wrote:
> > Since the virtio-gpu-ccw device depends on the hw-display-virtio-gpu
> > module, which provides the type virtio-gpu-device, packaging the
> > hw-disp
On Fri, 5 Mar 2021 12:54:42 +0100
Cornelia Huck wrote:
> On Tue, 2 Mar 2021 18:35:44 +0100
> Halil Pasic wrote:
>
> > Since the virtio-gpu-ccw device depends on the hw-display-virtio-gpu
> > module, which provides the type virtio-gpu-device, packaging the
> > h
On Tue, 2 Mar 2021 18:35:44 +0100
Halil Pasic wrote:
> Since the virtio-gpu-ccw device depends on the hw-display-virtio-gpu
> module, which provides the type virtio-gpu-device, packaging the
> hw-display-virtio-gpu module as a separate package that may or may not
> be ins
On Wed, 3 Mar 2021 08:07:50 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > The only approaches I can think of to make type_register_mayfail()
> > "work" involve adding a dependency check in type_register_internal()
> > before the call to type_table_add() is made. This can "work" for modules,
> >
390_flic.h was suggested
by Cornelia Huck.
Signed-off-by: Halil Pasic
---
As explained in [1] the previous idea of type_register_mayfail() does
not work. The next best thing is to check if all types we need are
already registered before registering virtio-gpu-ccw from the module. It
is reasonable to assume
On Wed, 24 Feb 2021 17:46:34 +0100
Halil Pasic wrote:
> On Wed, 24 Feb 2021 12:36:17 +0100
> Gerd Hoffmann wrote:
[..]
> >
> > > -static TypeImpl *type_register_internal(const TypeInfo *info)
> > > +static TypeImpl *type_register_internal(const TypeI
On Wed, 24 Feb 2021 12:36:17 +0100
Gerd Hoffmann wrote:
> > static void virtio_ccw_gpu_register(void)
> > {
> > +#ifdef CONFIG_MODULES
> > +type_register_static_mayfail(_ccw_gpu);
> > +#else
> > type_register_static(_ccw_gpu);
> > +#endif
>
> Move the ifdef to
On Mon, 22 Feb 2021 17:30:50 +
Daniel P. Berrangé wrote:
> > Paolo, Daniel,
> > I am in general (s390 unrelated) a bit puzzled about the scenario of QEMU
> > being modularized.
> > Libvirt probes QEMU executables for their capabilities and creates a
> > capabilities cache of the probed QEMU
enters did not like the
consequences of that.
Moving the interrupt related declarations to s390_flic.h was suggested
by Cornelia Huck.
Introducing type_register_mayfail() was suggested by Gerd Hoffmann.
Signed-off-by: Halil Pasic
---
hw/s390x/meson.build | 7 +-
hw/s390x/virtio-ccw-gpu
On Fri, 19 Feb 2021 09:45:45 +0100
Gerd Hoffmann wrote:
> > but that "fixes" s390x at the expense
> > of breaking all the other targets. For example:
> > ./qemu-system-x86_64 -device help
> > Type 'virtio-gpu-ccw' is missing its parent 'virtio-ccw-device'
> > Aborted
>
> Hmm, this is a new
On Thu, 18 Feb 2021 14:38:20 +0100
Gerd Hoffmann wrote:
> > > The explanation is simple. Unlike most devices, the ccw devices aren't
> > > portable. In particular both css.c and css.h includes "cpu.h", and
> > > virtio-ccw-gpu.c includes "qemu/osdep.h". Furthermore osdep.h contains:
> > > #ifdef
On Thu, 18 Feb 2021 14:51:09 +0100
Cornelia Huck wrote:
> On Wed, 17 Feb 2021 15:39:36 +0100
> Halil Pasic wrote:
>
> > On Tue, 16 Feb 2021 16:54:05 +0100
> > Cornelia Huck wrote:
> >
> > > On Tue, 16 Feb 2021 15:19:45 +0100
[..]
> >
> &g
On Thu, 18 Feb 2021 15:44:47 +0100
Thomas Huth wrote:
> On 18/02/2021 11.34, Halil Pasic wrote:
> > On Thu, 18 Feb 2021 10:23:16 +0100
> > Thomas Huth wrote:
> >
> >>> Since the virtio-gpu-ccw device depends on the hw-display-virtio-gpu
> >>> modu
On Thu, 18 Feb 2021 14:38:20 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > > The explanation is simple. Unlike most devices, the ccw devices aren't
> > > portable. In particular both css.c and css.h includes "cpu.h", and
> > > virtio-ccw-gpu.c includes "qemu/osdep.h". Furthermore osdep.h contains:
>
virtio-gpu-ccw built as a module, the correct way to package a
> > modularized qemu is to require that hw-display-virtio-gpu must be
> > installed whenever the module hw-s390x-virtio-gpu-ccw.
> >
> > Signed-off-by: Halil Pasic
> > ---
> > hw/s390x/
FIG_VIRTFS can't be used the way it was used here (see commit
2c9dce0196 ("meson: do not use CONFIG_VIRTFS")), the preconditions have
to be written differently.
Let's fix this!
Signed-off-by: Halil Pasic
Fixes: 2c44220d05 ("meson: convert hw/arch*")
Reported-by: Jakob Naucke
Cc:
-by: Halil Pasic
---
hw/s390x/meson.build | 17 -
util/module.c| 1 +
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/hw/s390x/meson.build b/hw/s390x/meson.build
index 2a7818d94b..153b1309fb 100644
--- a/hw/s390x/meson.build
+++ b/hw/s390x/meson.build
@@ -34,7
On Tue, 16 Feb 2021 16:54:05 +0100
Cornelia Huck wrote:
> On Tue, 16 Feb 2021 15:19:45 +0100
> Halil Pasic wrote:
>
> > On Tue, 16 Feb 2021 12:18:30 +0100
> > Cornelia Huck wrote:
> >
> > > The virtio standard specifies that any non-transitional dev
On Tue, 16 Feb 2021 17:15:19 +0100
Thomas Huth wrote:
> >> (Note: The virtio spec also talks about using a memory barrier
> >> *after* incrementing the idx field, but if I understood correctly
> >> this is only required when using notification suppression - which
> >> we don't use in the
On Tue, 16 Feb 2021 12:00:56 +0100
Thomas Huth wrote:
> According to the virtio specification, a memory barrier should be
> used before incrementing the idx field in the "available" ring.
> So far, we did not do this in the s390-ccw bios yet, but recently
> Peter Maydell saw problems with the
fix by setting revision to 0 if
> we see a non-revision command on a legacy-capable revision-less
> device.
>
> Signed-off-by: Cornelia Huck
The change won't hurt so with a toned down commit message:
Acked-by: Halil Pasic
> ---
> hw/s390x/virtio-ccw.c | 21 ++---
>
rprises.
>
> Signed-off-by: Christian Borntraeger
> Reviewed-by: David Hildenbrand
Reviewed-by: Halil Pasic
;
> However short of cleaning up the test to be more binary focused at
> least limit the attempt to dump the whole file as hexified zeros in
> the logs.
>
> Signed-off-by: Alex Bennée
Acked-by: Halil Pasic
Thanks!
> ---
> tests/acceptance/machine_s390_ccw_virtio.py | 2
On Mon, 4 Jan 2021 10:40:26 -0800
Ram Pai wrote:
> On Mon, Jan 04, 2021 at 01:46:29PM +0100, Halil Pasic wrote:
> > On Sun, 3 Jan 2021 23:15:50 -0800
> > Ram Pai wrote:
> >
> > > On Fri, Dec 18, 2020 at 12:41:11PM +0100, Cornelia Huck wrote:
> > &g
On Sun, 3 Jan 2021 23:15:50 -0800
Ram Pai wrote:
> On Fri, Dec 18, 2020 at 12:41:11PM +0100, Cornelia Huck wrote:
> > On Thu, 17 Dec 2020 15:15:30 +0100
[..]
> > > > > > > +int kvmppc_svm_init(SecurableGuestMemory *sgm, Error **errp)
> > > > > > > {
> > > > > > > if
On Tue, 15 Dec 2020 09:26:56 +0100
Cornelia Huck wrote:
> On Tue, 10 Nov 2020 14:18:39 +0100
> Christian Borntraeger wrote:
>
> > On 10.11.20 11:40, Halil Pasic wrote:
> > > On Tue, 10 Nov 2020 09:47:51 +0100
> > > Christian Borntraeger wrote:
> > >
On Tue, 8 Dec 2020 12:54:03 +1100
David Gibson wrote:
> > > >>> + * Virtio devices can't count on directly accessing guest
> > > >>> + * memory, so they need iommu_platform=on to use normal DMA
> > > >>> + * mechanisms. That requires also disabling legacy virtio
> > >
On Fri, 4 Dec 2020 09:29:59 +0100
Christian Borntraeger wrote:
>
>
> On 04.12.20 09:17, Cornelia Huck wrote:
> > On Fri, 4 Dec 2020 09:10:36 +0100
> > Christian Borntraeger wrote:
> >
> >> On 04.12.20 06:44, David Gibson wrote:
> >>> The default behaviour for virtio devices is not to use the
On Fri, 4 Dec 2020 13:25:00 +
Daniel P. Berrangé wrote:
> On Fri, Dec 04, 2020 at 01:07:27PM +, Dr. David Alan Gilbert wrote:
> > * Cornelia Huck (coh...@redhat.com) wrote:
> > > On Fri, 4 Dec 2020 09:06:50 +0100
> > > Christian Borntraeger wrote:
> > >
> > > > On 04.12.20 06:44, David
On Fri, 20 Nov 2020 12:38:37 +0100
Cornelia Huck wrote:
> On Fri, 20 Nov 2020 03:51:07 +0100
> Halil Pasic wrote:
>
> > On Tue, 17 Nov 2020 04:26:05 +0100
> > Eric Farman wrote:
> >
> > > Now that the vfio-ccw code has a notifier interface to request tha
On Tue, 17 Nov 2020 04:26:05 +0100
Eric Farman wrote:
> Now that the vfio-ccw code has a notifier interface to request that
> a device be unplugged, let's wire that together.
I'm aware of the fact that performing an unplug is what vfio-pci does,
but I was not aware of this before, and I became
On Wed, 11 Nov 2020 13:49:08 +0100
Michael Mueller wrote:
> Halil,
>
> still I would like to know what the exact memory consumption per queue
> is that you are talking about. Have you made a calculation? Thanks.
Hi!
The default size for virtio-blk seems to be 256 ring entries, which
On Tue, 10 Nov 2020 09:47:51 +0100
Christian Borntraeger wrote:
>
>
> On 09.11.20 19:53, Halil Pasic wrote:
> > On Mon, 9 Nov 2020 17:06:16 +0100
> > Cornelia Huck wrote:
> >
> >>> @@ -20,6 +21,11 @@ static void virtio_ccw_blk_realize(Virtio
On Mon, 9 Nov 2020 17:06:16 +0100
Cornelia Huck wrote:
> > @@ -20,6 +21,11 @@ static void virtio_ccw_blk_realize(VirtioCcwDevice
> > *ccw_dev, Error **errp)
> > {
> > VirtIOBlkCcw *dev = VIRTIO_BLK_CCW(ccw_dev);
> > DeviceState *vdev = DEVICE(>vdev);
> > +VirtIOBlkConf *conf =
t too much.
Suggested-by: Christian Borntraeger
Signed-off-by: Halil Pasic
---
We would prefer to land this for 5.2. If we do then commit 9445e1e15e
("virtio-blk-pci: default num_queues to -smp N") took care of all the
necessary compat handling.
If that's not possible, I will send
On Thu, 22 Oct 2020 04:23:12 -0400
Janosch Frank wrote:
> Diag318 fencing needs to be determined on the current VM PV state and
> not on the state that the VM has when we create the CPU model.
>
> Signed-off-by: Janosch Frank
> Reported-by: Marc Hartmayer
> Reviewed-by: Christian Borntraeger
ting a false boundary cross error.
>
> Signed-off-by: Janosch Frank
> Reported-by: Marc Hartmayer
> Fixes: db13387ca0 ("s390/sclp: rework sclp boundary checks")
> Reviewed-by: Christian Borntraeger
> Tested-by: Marc Hartmayer
Acked-by: Halil Pasic
> ---
>
properly re-enabled afterwards. Add the S390 PCI host bridge to the list
> of qdevs to be reset during subsystem reset.
>
> Signed-off-by: Matthew Rosato
> Reviewed-by: Eric Farman
Acked-by: Halil Pasic
> ---
> hw/s390x/s390-virtio-ccw.c | 1 +
> 1 file changed, 1 insert
On Fri, 11 Sep 2020 12:04:42 +1000
David Gibson wrote:
> On Mon, Sep 07, 2020 at 05:10:46PM +0200, Halil Pasic wrote:
> > On Fri, 24 Jul 2020 12:57:43 +1000
> > David Gibson wrote:
> >
> > > The default behaviour for virtio devices is not to use the platforms
On Fri, 11 Sep 2020 10:07:18 +1000
David Gibson wrote:
> On Thu, Sep 10, 2020 at 08:29:24PM +0200, Halil Pasic wrote:
> > On Thu, 10 Sep 2020 13:36:09 +0200
> > Cornelia Huck wrote:
> >
> > > On Mon, 7 Sep 2020 17:22:53 +0200
> > > Halil Pasic wrote:
&
On Thu, 10 Sep 2020 13:36:09 +0200
Cornelia Huck wrote:
> On Mon, 7 Sep 2020 17:22:53 +0200
> Halil Pasic wrote:
>
> > On Fri, 24 Jul 2020 12:57:44 +1000
> > David Gibson wrote:
> >
> > > At least some s390 cpu models support "Protected Virtualiz
On Fri, 3 Jul 2020 12:06:50 +0200
Cornelia Huck wrote:
> From: Halil Pasic
>
> The atomic_cmpxchg() loop is broken because we occasionally end up with
> old and _old having different values (a legit compiler can generate code
> that accessed *ind_addr again to pick up a value f
On Fri, 3 Jul 2020 12:06:49 +0200
Cornelia Huck wrote:
> From: Halil Pasic
>
> The atomic_cmpxchg() loop is broken because we occasionally end up with
> old and _old having different values (a legit compiler can generate code
> that accessed *ind_addr again to pick up a value f
omething like follows as a part of this series.
8<--
From: Halil Pasic
Date: Mon, 7 Sep 2020 15:00:17 +0200
Subject: [PATCH] virtio: handle host trust limitation
If host_trust_limitation_enabled() returns true, then emulated virtio
devices must of
On Fri, 24 Jul 2020 12:57:43 +1000
David Gibson wrote:
> The default behaviour for virtio devices is not to use the platforms normal
> DMA paths, but instead to use the fact that it's running in a hypervisor
> to directly access guest memory. That doesn't work if the guest's memory
> is
-by: Cornelia Huck
Reviewed-by: Halil Pasic
> ---
> hw/s390x/virtio-ccw.c | 1 +
> hw/virtio/virtio-pci.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> index 0e602702971b..8feb3451a098 100644
> --- a/hw/s390x/
ID 1431058
Reported-by: Peter Maydell
Signed-off-by: Halil Pasic
---
hw/s390x/s390-virtio-ccw.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 403d30e13b..e72c61d2ea 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/h
On Thu, 30 Jul 2020 11:25:06 +0100
Daniel P. Berrangé wrote:
> > /* make a NUL-terminated string */
> > -loadparm_str = g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1);
> > -loadparm_str[sizeof(ms->loadparm)] = 0;
> > +loadparm_str = g_malloc0(sizeof(ms->loadparm) + 1);
> > +
On Thu, 30 Jul 2020 12:26:56 +0200
Cornelia Huck wrote:
> On Wed, 29 Jul 2020 15:02:22 +0200
> Halil Pasic wrote:
>
> > As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1)
> > reads one past of the end of ms->loadparm, so g_mem
overity CID 1431058
Reported-by: Peter Maydell
Signed-off-by: Halil Pasic
---
hw/s390x/s390-virtio-ccw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 403d30e13b..8b7bac0392 100644
--- a/hw/s390x/s390-virtio-ccw.c
On Tue, 28 Jul 2020 17:14:38 +0200
Cornelia Huck wrote:
> On Tue, 28 Jul 2020 14:52:36 +0100
> Peter Maydell wrote:
>
> > On Mon, 27 Jul 2020 at 15:05, Cornelia Huck wrote:
> > >
> > > From: Halil Pasic
> > >
> > > The function machi
On Tue, 28 Jul 2020 12:48:50 +0200
Cornelia Huck wrote:
> On Tue, 21 Jul 2020 18:44:56 +0200
> Halil Pasic wrote:
>
> > On Tue, 21 Jul 2020 09:40:10 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > On Fri, Jul 17, 2020 at 11:29:28AM +0200, Marc H
On Tue, 28 Jul 2020 12:31:51 +0200
Cornelia Huck wrote:
> On Fri, 17 Jul 2020 11:29:27 +0200
> Marc Hartmayer wrote:
>
> > From: Halil Pasic
> >
> > Wire up the CCW device for vhost-user-fs.
> >
> > Signed-off-by: Halil Pasic
> > ---
> >
On Thu, 23 Jul 2020 18:37:50 +0200
Thomas Huth wrote:
> On 23/07/2020 18.27, Halil Pasic wrote:
> > The function machine_get_loadparm() is supposed to produce as C-string,
>
> sed "s/ as / a /"
>
Nod.
> > that is a null-terminated one, but it does not. E
The function machine_get_loadparm() is supposed to produce as C-string,
that is a null-terminated one, but it does not. ElectricFence can detect
this problem if the loadparm machine property is used.
Let us make the returned string a null-terminated one.
Signed-off-by: Halil Pasic
Fixes
On Tue, 21 Jul 2020 09:40:10 -0400
"Michael S. Tsirkin" wrote:
> On Fri, Jul 17, 2020 at 11:29:28AM +0200, Marc Hartmayer wrote:
> > Since virtio existed even before it got standardized, the virtio
> > standard defines the following types of virtio devices:
> >
> > + legacy device (pre-virtio
d does not force anything. I'm unsure whether we should
> consider transitional virtio-iommu unsupported, or if we should add
> some compat handling. (The support for legacy or not generally may
> change based upon the bus, IIUC, so I'm unsure how to come up with
> something generic.
On Fri, 3 Jul 2020 12:06:50 +0200
Cornelia Huck wrote:
> From: Halil Pasic
>
> The atomic_cmpxchg() loop is broken because we occasionally end up with
> old and _old having different values (a legit compiler can generate code
> that accessed *ind_addr again to pick up a value f
On Fri, 3 Jul 2020 12:06:49 +0200
Cornelia Huck wrote:
> From: Halil Pasic
>
> The atomic_cmpxchg() loop is broken because we occasionally end up with
> old and _old having different values (a legit compiler can generate code
> that accessed *ind_addr again to pick up a value f
On Sat, 4 Jul 2020 14:34:04 -0400
"Michael S. Tsirkin" wrote:
> On Tue, Jun 16, 2020 at 06:50:34AM +0200, Halil Pasic wrote:
> > The atomic_cmpxchg() loop is broken because we occasionally end up with
> > old and _old having different values (a legit compiler can genera
On Wed, 1 Jul 2020 14:06:11 +0200
Christian Borntraeger wrote:
>
>
> On 01.07.20 14:01, Cornelia Huck wrote:
> > On Tue, 16 Jun 2020 06:50:33 +0200
> > Halil Pasic wrote:
> >
> >> The story short: compiler can generate code that does two
> >> d
On Fri, 26 Jun 2020 14:49:37 +0200
Janosch Frank wrote:
> On 6/26/20 12:58 PM, Daniel P. Berrangé wrote:
> > On Fri, Jun 26, 2020 at 11:29:03AM +0100, Dr. David Alan Gilbert wrote:
> >> * Janosch Frank (fran...@linux.ibm.com) wrote:
> >>> On 6/26/20 11:32 AM, Daniel P. Berrangé wrote:
> On
On Thu, 25 Jun 2020 11:19:35 +0100
Daniel P. Berrangé wrote:
> On Thu, Jun 25, 2020 at 12:04:26PM +0200, Marc Hartmayer wrote:
> > This RFC is about enabling virtio-fs on s390x. For that we need
> > + some shim code (first patch), and we need
> > + libvhost-user to deal with virtio endiannes
On Thu, 25 Jun 2020 12:17:55 +0200
Cornelia Huck wrote:
> On Thu, 25 Jun 2020 12:04:26 +0200
> Marc Hartmayer wrote:
>
> > This RFC is about enabling virtio-fs on s390x. For that we need
> > + some shim code (first patch), and we need
> > + libvhost-user to deal with virtio endiannes as
On Fri, 19 Jun 2020 13:16:38 +0100
Daniel P. Berrangé wrote:
[..]
> > > > > @@ -1165,6 +1167,15 @@ void machine_run_board_init(MachineState
> > > > > *machine)
> > > > > * areas.
> > > > > */
> > > > > machine_set_mem_merge(OBJECT(machine), false, _abort);
> > > >
On Fri, 19 Jun 2020 09:33:44 +0200
David Hildenbrand wrote:
> On 18.06.20 01:56, Halil Pasic wrote:
> > On Tue, 16 Jun 2020 08:33:33 +0200
> > Cornelia Huck wrote:
> >
> >>> #define atom
On Tue, 16 Jun 2020 08:33:33 +0200
Cornelia Huck wrote:
> > #define atomic_cmpxchg__nocheck(ptr, old, new)({\
> >
> >
> > typeof_strip_qual(*ptr) _old = (old); \
> >
> >
> > (void)__atomic_compare_exchange_n(ptr, &_old,
On Tue, 16 Jun 2020 07:58:53 +0200
Christian Borntraeger wrote:
>
>
> On 16.06.20 06:50, Halil Pasic wrote:
> > The atomic_cmpxchg() loop is broken because we occasionally end up with
> > old and _old having different values (a legit compiler can generate code
> > th
that the
new old is used to compute the new desired value if the xchg part
is not performed.
Signed-off-by: Halil Pasic
Fixes: 8cba80c3a0 ("s390: Add PCI bus support")
Reported-by: Christian Borntraeger
---
hw/s390x/s390-pci-bus.c | 16 +---
1 file changed, 9 insertions(+), 7 deletion
that the
new old is used to compute the new desired value if the xchg part
is not performed.
Signed-off-by: Halil Pasic
Reported-by: Andre Wild
Fixes: 7e7494627f ("s390x/virtio-ccw: Adapter interrupt support.")
---
hw/s390x/virtio-ccw.c | 18 ++
1 file changed, 10 insertions(+), 8
The story short: compiler can generate code that does two
distinct fetches of *ind_addr for old and _old. If that happens we can
not figure out if we had the desired xchg or not.
Halil Pasic (2):
virtio-ccw: fix virtio_set_ind_atomic
s390x/pci: fix set_ind_atomic
hw/s390x/s390-pci-bus.c
On Wed, 10 Jun 2020 14:25:54 +1000
David Gibson wrote:
> > > I'm going to definitely have a good look at that. What I think special
> > > about s390 is that F_ACCESS_PLATFORM is hurting us because all IO needs
> > > to go through ZONE_DMA (this is a problem of the implementation that
> > >
On Wed, 10 Jun 2020 14:29:29 +1000
David Gibson wrote:
> On Tue, Jun 09, 2020 at 06:28:39PM +0200, Halil Pasic wrote:
> > On Tue, 9 Jun 2020 17:47:47 +0200
> > Claudio Imbrenda wrote:
> >
> > > On Tue, 9 Jun 2020 11:41:30 +0200
> > > Halil Pasic wro
0400, Michael S. Tsirkin wrote:
> >>>> On Tue, Jun 09, 2020 at 06:28:39PM +0200, Halil Pasic wrote:
> >>>>> On Tue, 9 Jun 2020 17:47:47 +0200
> >>>>> Claudio Imbrenda wrote:
> >>>>>
> >>>>>> On Tue, 9 Jun 2020 1
On Wed, 10 Jun 2020 10:48:42 +0200
Cornelia Huck wrote:
> On Wed, 10 Jun 2020 14:39:22 +1000
> David Gibson wrote:
>
> > On Tue, Jun 09, 2020 at 12:16:41PM +0200, Cornelia Huck wrote:
> > > On Sun, 7 Jun 2020 13:07:35 +1000
> > > David Gibson wrote:
> > >
> > > > On Sat, Jun 06, 2020 at
On Tue, 9 Jun 2020 18:05:59 +0200
Cornelia Huck wrote:
> Which devices are compatible in the end? It seems the only ones that
> are known to be working are virtio-ccw devices with IOMMU_PLATFORM on.
> virtio-pci devices and non-virtio ccw (vfio-ccw, 3270) seem to be out,
> as far as I understand
On Tue, 9 Jun 2020 12:44:39 -0400
"Michael S. Tsirkin" wrote:
> On Tue, Jun 09, 2020 at 06:28:39PM +0200, Halil Pasic wrote:
> > On Tue, 9 Jun 2020 17:47:47 +0200
> > Claudio Imbrenda wrote:
> >
> > > On Tue, 9 Jun 2020
On Tue, 9 Jun 2020 18:05:59 +0200
Cornelia Huck wrote:
> >
> > do we really have that many incompatible devices?
>
> Which devices are compatible in the end? It seems the only ones that
> are known to be working are virtio-ccw devices with IOMMU_PLATFORM on.
> virtio-pci devices and
101 - 200 of 1024 matches
Mail list logo
