o table_translate() is always called with a valid ett value.
>
> Instead of having the various functions called from table_translate()
> return a default or dummy value when the ett argument is out of range,
> use g_assert_not_reached() to indicate that this is impossible.
>
> Co
em
> unfixed in the "loadparm" device property. Fix it.
>
> Signed-off-by: Kevin Wolf
Reviewed-by: Halil Pasic
On Mon, 23 Jun 2025 12:00:30 -0400
Matthew Rosato wrote:
> To improve review coverage, assign additional people as reviewers for
> multiple s390 sections.
>
> Signed-off-by: Matthew Rosato
Acked-by: Halil Pasic
elper_diag ../target/s390x/tcg/misc_helper.c:137:9
> #13 0x7f1a3c51c730 (/memfd:tcg-jit (deleted)+0x39730)
>
> Signed-off-by: Fabiano Rosas
Reviewed-by: Halil Pasic
> #include "exec/ram_addr.h"
> #include "qapi/error.h"
> -#include "qapi/qmp/qdict.h"
> +#include "qobject/qdict.h"
> #include "cpu.h"
Acked-by: Halil Pasic #s390x
On Tue, 1 Oct 2024 11:15:02 +0200
Christian Borntraeger wrote:
[..]
> >> So 500+4 should probably not cause any harm apart from branch prediction
> >> going wrong the first 2 or 3 notifies.
> >>
> >> 502 will make kvm_s390_handle_diag larger.
> >
> > What do you mean by this last paragraph?
[..
On Fri, 27 Sep 2024 20:29:19 +0200
David Hildenbrand wrote:
> On 27.09.24 20:20, Halil Pasic wrote:
> > On Wed, 11 Sep 2024 21:09:27 +0200
> > David Hildenbrand wrote:
> >
> >>> Anyway, if we want to proceed with the gitlab project, would it make
> >&g
On Mon, 30 Sep 2024 13:11:31 +0200
Christian Borntraeger wrote:
> We do have kvm_stat counters for 500, not sure if people debugging virtio
> will care.
Could end up being confusing, as currently we can assume each and every
DIAG 500 is a virtio doorbell. But I don't think the chance of this
cau
On Thu, 12 Sep 2024 10:19:00 +0200
Thomas Huth wrote:
> > diff --git a/hw/s390x/s390-hypercall.h b/hw/s390x/s390-hypercall.h
> > index b7ac29f444..f0ca62bcbb 100644
> > --- a/hw/s390x/s390-hypercall.h
> > +++ b/hw/s390x/s390-hypercall.h
> > @@ -18,6 +18,7 @@
> > #define DIAG500_VIRTIO_RESET
On Wed, 11 Sep 2024 21:09:27 +0200
David Hildenbrand wrote:
> > Anyway, if we want to proceed with the gitlab project, would it make
> > sense to create an org for it, so that it doesn't look like David's
> > personal project?
Frankly, I would prefer making Documentation/virt/kvm/s390/s390-diag.
On Thu, 30 May 2024 10:34:55 +0800
Jason Wang wrote:
> >
> > IMHO changing the semantic of the VHOST_GET_FEATURES ioctl is not viable,
> > but also not necessary. What I am proposing is changing the (in QEMU)
> > logic of processing the features returned by VHOST_GET_FEATURES, while
> > preservin
On Tue, 28 May 2024 17:32:26 +0200
Stefano Garzarella wrote:
> >1) The uses is explicitly asking for a vhost device and giving the user
> >a non vhost device is not an option.
>
> I didn't get this point :-( can you elaborate?
I was thinking along the lines: QEMU gets told what devices to
pro
On Tue, 28 May 2024 11:25:51 +0800
Jason Wang wrote:
> > 5) Based on the following, I would very much prefer a per device list of
> > features with the semantic "hey QEMU can do that feature without any
> > specialized vhost-device support (e.g. like VIRTIO_SCSI_F_CHANGE)"
>
> Indeed the curre
On Thu, 16 May 2024 10:39:42 +0200
Stefano Garzarella wrote:
[..]
> >---
> >
> >This is a minimal fix, that follows the current patterns in the
> >codebase, and not necessarily the best one.
>
> Yeah, I did something similar with commit 562a7d23bf ("vhost: mask
> VIRTIO_F_RING_RESET for vhost
On Tue, 7 May 2024 21:26:30 +0200
Halil Pasic wrote:
> > Not having VIRTIO_F_RING_PACKED in feature_bits[] is a problem when the
> > vhost-vsock device does not offer the feature bit VIRTIO_F_RING_PACKED
> > but the in QEMU device is configured to try to use the packed layo
On Mon, 29 Apr 2024 13:33:34 +0200
Halil Pasic wrote:
> Not having VIRTIO_F_RING_PACKED in feature_bits[] is a problem when the
> vhost-vsock device does not offer the feature bit VIRTIO_F_RING_PACKED
> but the in QEMU device is configured to try to use the packed layout
> (the vir
rt it, and
one gets to keep the pieces.
Fixes: 74b3e46630 ("virtio: add property to enable packed virtqueue")
Reported-by: Marc Hartmayer
Signed-off-by: Halil Pasic
---
This is a minimal fix, that follows the current patterns in the
codebase, and not necessarily the best one.
I don&#x
On Mon, 22 Jan 2024 10:06:38 -0500
Matthew Rosato wrote:
> On 1/19/24 4:07 PM, Halil Pasic wrote:
> > On Thu, 18 Jan 2024 13:51:51 -0500
> > Matthew Rosato wrote:
> >
> >> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> >> index e
all that method
> in the hold phase of 3-phase reset.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Halil Pasic
On Thu, 18 Jan 2024 13:51:51 -0500
Matthew Rosato wrote:
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index eaf61d3640..c99682b07d 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -118,6 +118,14 @@ static void subsystem_reset(void)
>
INERS: split out s390x sections")
> Signed-off-by: Eric Farman
Reviewed-by: Halil Pasic
u_check_nic_model() - and this in turn calls qemu_find_nic_model()
> which contains the same check for nd->model being NULL again. So we
> can remove this from the calling site now.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Halil Pasic
On Thu, 11 May 2023 14:20:51 +0200
Markus Armbruster wrote:
[..]
> >
> > In my opinion the best way to deal with such situations would be to
> > abort() in test/development and log a warning in production. Of course
>
> Understand, but...
>
> > assert() wouldn't give me that, and it wouldn't b
On Wed, 10 May 2023 08:32:12 +0200
Markus Armbruster wrote:
> Halil Pasic writes:
>
> > On Mon, 08 May 2023 11:01:55 +0200
> > Cornelia Huck wrote:
> >
> >> On Mon, May 08 2023, Markus Armbruster wrote:
[..]
> > and we do check for availability
On Mon, 08 May 2023 11:01:55 +0200
Cornelia Huck wrote:
> On Mon, May 08 2023, Markus Armbruster wrote:
>
> > css_clear_io_interrupt() aborts on unexpected ioctl() errors, and I
> > wonder whether that's appropriate. Let's have a closer look:
Just for my understanding, was there a field probl
On Mon, 27 Mar 2023 08:29:09 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Mar 27, 2023 at 01:06:19PM +0200, Cornelia Huck wrote:
> > On Wed, Mar 22 2023, Halil Pasic wrote:
> >
> > > On Wed, 22 Mar 2023 10:52:31 +0100
> > > Cornelia Huck wrote:
>
On Wed, 22 Mar 2023 18:24:33 +0100
Halil Pasic wrote:
> > > --- a/hw/s390x/virtio-ccw.c
> > > +++ b/hw/s390x/virtio-ccw.c
> > > @@ -237,6 +237,7 @@ static int virtio_ccw_set_vqs(SubchDev *sch,
> > > VqInfoBlock *info,
&
On Wed, 22 Mar 2023 10:52:31 +0100
Cornelia Huck wrote:
[..]
> >
> > diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> > index e33e5207ab..f44de1a8c1 100644
> > --- a/hw/s390x/virtio-ccw.c
> > +++ b/hw/s390x/virtio-ccw.c
> > @@ -237,6 +237,7 @@ static int virtio_ccw_set_vqs(SubchDev *sc
On Tue, 24 May 2022 12:43:29 +0200
Thomas Huth wrote:
> On 19/05/2022 15.53, Janis Schoetterl-Glausch wrote:
> > On 5/19/22 12:05, Thomas Huth wrote:
> >> On 06/05/2022 17.39, Janis Schoetterl-Glausch wrote:
> >>> Storage key controlled protection is currently not honored when
> >>> emulating
On Mon, 28 Mar 2022 16:30:19 +0200
Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini
Reviewed-by: Halil Pasic
#include "net/net.h"
> #include "hw/virtio/virtio.h"
> @@ -19,6 +20,7 @@
> #include "hw/virtio/virtio-net.h"
> #include "qemu/bitops.h"
> #include "qemu/error-report.h"
> +#include "qemu/log.h"
Unrelated?
Reviewed-by: Halil Pasic
On Mon, 28 Mar 2022 16:30:17 +0200
Paolo Bonzini wrote:
> Remove unecessary use of #ifdef CONFIG_VHOST_SCSI, instead just use a
> separate file and a separate rule in meson.build.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Halil Pasic
is only the case for the default configuration of QEMU's s390x
> target.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Halil Pasic
LGTM
For the s390x parts I'm involved in:
Acked-by: Halil Pasic
[..]
> --- a/include/exec/cpu-all.h
> +++ b/include/exec/cpu-all.h
> @@ -34,13 +34,13 @@
>
> /* some important defines:
> *
> - * HOST_WORDS_BIGENDIAN : if defined, the host cpu is big endian and
> + * HO
On Wed, 16 Mar 2022 11:28:59 +0100
Thomas Huth wrote:
> On 16/03/2022 10.53, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau
> >
> > Replace a config-time define with a compile time condition
> > define (compatible with clang and gcc) that must be declared prior to
> > its usage.
ping
On Mon, 7 Mar 2022 12:29:39 +0100
Halil Pasic wrote:
> Unlike most virtio features ACCESS_PLATFORM is considered mandatory by
> QEMU, i.e. the driver must accept it if offered by the device. The
> virtio specification says that the driver SHOULD accept the
> ACCESS_PLATFOR
ause the driver didn't negotiate
ACCESS_PLATFORM.
So let us make ACCESS_PLATFORM mandatory for the driver regardless
of whether the get_dma_as() callback is implemented or not.
Signed-off-by: Halil Pasic
Fixes: 2943b53f68 ("virtio: force VIRTIO_F_IOMMU_PLATFORM")
---
v2 -> v3:
On Sun, 6 Mar 2022 05:15:20 -0500
"Michael S. Tsirkin" wrote:
> I tried to apply this on top of
> virtio: fix the condition for iommu_platform not supported
> and it fails.
> Can you rebase this on top of my tree pls?
Will do right away! BTW I don't think your tree is mentioned
in the MAINTA
ause the driver didn't negotiate
ACCESS_PLATFORM.
So let us make ACCESS_PLATFORM mandatory for the driver regardless
of whether the get_dma_as() callback is implemented or not.
Signed-off-by: Halil Pasic
Fixes: 2943b53f68 ("virtio: force VIRTIO_F_IOMMU_PLATFORM")
---
v2 -> v2:
*
On Fri, 4 Mar 2022 03:12:03 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 10, 2022 at 02:29:29PM +0100, Halil Pasic wrote:
> > On Thu, 10 Feb 2022 12:19:25 +0100
> > Cornelia Huck wrote:
> >
> > [..]
> > >
> > > Nope, that's
olution to 1280x800 (WXGA)")
> Signed-off-by: Thomas Huth
Looks good!
Acked-by: Halil Pasic
> ---
> tests/avocado/machine_s390_ccw_virtio.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/avocado/machine_s390_ccw_virtio.py
> b/tests/av
On Thu, 10 Feb 2022 12:19:25 +0100
Cornelia Huck wrote:
[..]
>
> Nope, that's not my problem. We make sure that the bit is persistent, we
> fail realization if the bit got removed by the callback when required,
> and we fail feature validation if the driver removes the bit, which is
> in a diffe
On Thu, 10 Feb 2022 10:55:13 +0100
Cornelia Huck wrote:
> On Wed, Feb 09 2022, Halil Pasic wrote:
>
> > On Wed, 09 Feb 2022 18:24:56 +0100
> > Cornelia Huck wrote:
> >
> >> On Wed, Feb 09 2022, Halil Pasic wrote:
> >> > @@ -78,16 +78,19 @
On Wed, 09 Feb 2022 18:24:56 +0100
Cornelia Huck wrote:
> On Wed, Feb 09 2022, Halil Pasic wrote:
>
> > Unlike most virtio features ACCESS_PLATFORM is considered mandatory by
> > QEMU, i.e. the driver must accept it if offered by the device. The
> > virtio specificat
ause the driver didn't negotiate
ACCESS_PLATFORM.
So let us make ACCESS_PLATFORM mandatory for the driver regardless
of whether the get_dma_as() callback is implemented or not.
Signed-off-by: Halil Pasic
Fixes: 2943b53f68 ("virtio: force VIRTIO_F_IOMMU_PLATFORM")
---
RFC -> v1:
On Mon, 7 Feb 2022 16:46:04 -0300
Daniel Henrique Barboza wrote:
> On 2/7/22 11:46, Halil Pasic wrote:
> > On Mon, 7 Feb 2022 08:46:34 -0300
> > Daniel Henrique Barboza wrote:
> >
> > I have considered this and decided against it. The reason why is
> > if
On Mon, 07 Feb 2022 16:21:31 +0100
Cornelia Huck wrote:
> On Mon, Feb 07 2022, Halil Pasic wrote:
>
> > On Mon, 07 Feb 2022 14:41:58 +0100
> > Cornelia Huck wrote:
>
> >> OTOH, the decision to make it mandatory is certainly sound, and covered
> >
On Mon, 07 Feb 2022 14:41:58 +0100
Cornelia Huck wrote:
> On Mon, Feb 07 2022, Daniel Henrique Barboza wrote:
>
> > On 2/3/22 13:45, Halil Pasic wrote:
> >> Unlike most virtio features ACCESS_PATFORM is considered mandatory, i.e.
>
> s/ACCESS_PATFORM
On Mon, 7 Feb 2022 08:46:34 -0300
Daniel Henrique Barboza wrote:
> On 2/3/22 13:45, Halil Pasic wrote:
> > Unlike most virtio features ACCESS_PATFORM is considered mandatory, i.e.
> > the driver must accept it if offered by the device. The virtio
> > specification says t
On Fri, 4 Feb 2022 20:15:27 -0500
"Michael S. Tsirkin" wrote:
> On Sat, Feb 05, 2022 at 01:02:05AM +0100, Halil Pasic wrote:
> > On Fri, 4 Feb 2022 08:05:25 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Thu, Feb 03, 2022 at 05:06:35PM
s no device capability is needed. In this
situation claiming that the device does not support iommu_plattform=on
is counter-productive. So let us stop doing that!
Signed-off-by: Halil Pasic
Reported-by: Jakob Naucke
Fixes: 04ceb61a40 ("virtio: Fail if iommu_platform is requested, but
unsup
On Fri, 4 Feb 2022 08:05:25 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 03, 2022 at 05:06:35PM +0100, Halil Pasic wrote:
> > On Wed, 2 Feb 2022 20:54:38 +0100
> > Halil Pasic wrote:
> >
> > > }
> > > @@ -82,9 +78,14 @@ void virtio_bu
On Thu, 3 Feb 2022 20:37:56 +0100
Philippe Mathieu-Daudé via wrote:
> CPUS390XState is declared in "cpu.h".
>
> Signed-off-by: Philippe Mathieu-Daudé
No objections :)
Acked-by: Halil Pasic
dless
of whether the get_dma_as() callback is implemented or not.
Signed-off-by: Halil Pasic
Fixes: 2943b53f68 ("virtio: force VIRTIO_F_IOMMU_PLATFORM")
---
This patch is based on:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg866199.html
During the review of "virtio: fix t
On Wed, 2 Feb 2022 20:54:38 +0100
Halil Pasic wrote:
> }
> @@ -82,9 +78,14 @@ void virtio_bus_device_plugged(VirtIODevice *vdev, Error
> **errp)
> return;
> }
>
> +vdev_has_iommu = virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM);
>
s no device capability is needed. In this
situation claiming that the device does not support iommu_plattform=on
is counter-productive. So let us stop doing that!
Signed-off-by: Halil Pasic
Reported-by: Jakob Naucke
Fixes: 04ceb61a40 ("virtio: Fail if iommu_platform is requested, but
unsup
On Wed, 2 Feb 2022 10:24:51 -0300
Daniel Henrique Barboza wrote:
> On 2/1/22 22:15, Halil Pasic wrote:
> > On Tue, 1 Feb 2022 16:31:22 -0300
> > Daniel Henrique Barboza wrote:
> >
> >> On 2/1/22 15:33, Halil Pasic wrote:
> >>> On Tue, 1 Feb 2022 12
On Wed, 2 Feb 2022 02:06:12 -0500
"Michael S. Tsirkin" wrote:
[..]
> > In my opinion not forcing the guest to negotiate IOMMU_PLATFORM when
> > ->get_dma_as() is not set is at least unfortunate. Please observe, that
> > virtio-pci is not affected by this omission because for virtio-pci
> > de
On Tue, 1 Feb 2022 16:31:22 -0300
Daniel Henrique Barboza wrote:
> On 2/1/22 15:33, Halil Pasic wrote:
> > On Tue, 1 Feb 2022 12:36:25 -0300
> > Daniel Henrique Barboza wrote:
> >
> >>> +vdev_has_iommu = virtio_host_has_feature(vdev,
> >>&
On Tue, 1 Feb 2022 12:36:25 -0300
Daniel Henrique Barboza wrote:
> > +vdev_has_iommu = virtio_host_has_feature(vdev,
> > VIRTIO_F_IOMMU_PLATFORM);
> > if (klass->get_dma_as != NULL && has_iommu) {
> > virtio_add_feature(&vdev->host_features, VIRTIO_F_IOMMU_PLATFORM);
> >
On Tue, 1 Feb 2022 11:52:06 -0500
"Michael S. Tsirkin" wrote:
> > > +bool vdev_has_iommu = false;
> >
> > Isn't vdev_has_iommu set unconditionally before you try to use it?
>
> I'd like to know too.
Yes it is. Was meant as a conservative thing. AFAIR in C stuff on stack
is not initiali
On Tue, 1 Feb 2022 14:39:15 +0100
Halil Pasic wrote:
> The commit 04ceb61a40 ("virtio: Fail if iommu_platform is requested, but
> unsupported") claims to fail the device hotplug when iommu_platform
CC-ing Daniel with his new email address.
evice, and thus no device capability is needed. In this
situation claiming that the device does not support iommu_plattform=on
is counter-productive. So let us stop doing that!
Signed-off-by: Halil Pasic
Reported-by: Jakob Naucke
Fixes: 04ceb61a40 ("virtio: Fail if iommu_platform is requested,
On Fri, 28 Jan 2022 08:02:39 -0300
Daniel Henrique Barboza wrote:
> > We may be able to differentiate between the two using ->dma_as, but for
> > that it needs to be set up correctly: whenever you require translation
> > it should be something different than address_space_memory. The question
> >
On Thu, 27 Jan 2022 18:34:23 -0300
Daniel Henrique Barboza wrote:
> On 1/27/22 10:28, Halil Pasic wrote:
> > ping^2
> >
> > Also adding Brijesh and Daniel, as I believe you guys should be
> > interested in this, and I'm yet to receive review.
> >
> >
21:12 +0100
Halil Pasic wrote:
> ping
>
> On Mon, 17 Jan 2022 13:02:38 +0100
> Halil Pasic wrote:
>
> > The commit 04ceb61a40 ("virtio: Fail if iommu_platform is requested, but
> > unsupported") claims to fail the device hotplug when iommu_platform
> &g
ping
On Mon, 17 Jan 2022 13:02:38 +0100
Halil Pasic wrote:
> The commit 04ceb61a40 ("virtio: Fail if iommu_platform is requested, but
> unsupported") claims to fail the device hotplug when iommu_platform
> is requested, but not supported by the (vhost) device. On the
evice, and thus no device capability is needed. In this
situation claiming that the device does not support iommu_plattform=on
is counter-productive. So let us stop doing that!
Signed-off-by: Halil Pasic
Reported-by: Jakob Naucke
Fixes: 04ceb61a40 ("virtio: Fail if iommu_platform is requested,
On Thu, 13 Jan 2022 20:54:52 +0100
Halil Pasic wrote:
> > > This is the very reason for which commit 7ef7e6e3b ("vhost: correctly
> > > turn on VIRTIO_F_IOMMU_PLATFORM") for, which fences _F_ACCESS_PLATFORM
> > > form the vhost device that does not need it,
On Thu, 13 Jan 2022 12:11:42 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Jan 13, 2022 at 05:51:31PM +0100, Halil Pasic wrote:
> > The commit 04ceb61a40 ("virtio: Fail if iommu_platform is requested, but
> > unsupported") claims to fail the device hotplug when i
same condition for detecting the
situation when _F_ACCESS_PLATFORM is requested, but no I/O translation
by the device, and thus no device capability is needed. In this
situation claiming that the device does not support iommu_plattform=on
is counter-productive. So let us stop doing that!
Si
On Wed, 12 Jan 2022 17:40:44 +0100
Eric Farman wrote:
> After the recent restructuring, I'd like to volunteer to help
> in some of the s390 I/O areas.
>
> Built on "[PATCH RFC v2] MAINTAINERS: split out s390x sections"
>
> Signed-off-by: Eric Farman
6 and 7 need to be zero.
> >
> > As both PMCW_FLAGS_MASK_INVALID and ioinst_schib_valid() are only used
> > by ioinst_handle_msch(), adjust the mask accordingly.
> >
> > Fixes: db1c8f53bfb1 ("s390: Channel I/O basic definitions.")
> > Signed-off-by: N
On Tue, 21 Dec 2021 17:11:58 +0100
Cornelia Huck wrote:
> Any objections if I move the sections as outlined above and keep the
> acks I already have?
No objections here!
Regards,
Halil
On Mon, 20 Dec 2021 12:54:19 +0100
Cornelia Huck wrote:
> Split out some more specialized devices etc., so that we can build
> smarter lists of people to be put on cc: in the future.
>
> Signed-off-by: Cornelia Huck
LGTM
Acked-by: Halil Pasic
On Mon, 20 Dec 2021 11:44:44 +0100
Pierre Morel wrote:
> >
> > The PoP says that the machine shall ignore other fields
> > of the PMCW when an MSCH is performed. I.e. we should not update
> > "our" pmcw.flags bit 5 from 0 to 1 even if 1 was supplied, and
> > thus STSCH should keep storing the bi
On Fri, 17 Dec 2021 18:13:47 +0100
Pierre Morel wrote:
> >> Previously, we required bits 5, 6 and 7 to be zero (0x07 == 0b111). But,
> >> as per the principles of operation, bit 5 is ignored in MSCH and bits 0,
> >> 1, 6 and 7 need to be zero.
> >
> > On a second thought, don't we have to make
On Fri, 17 Dec 2021 14:58:11 +0100
Halil Pasic wrote:
> On Thu, 16 Dec 2021 14:16:57 +0100
> Nico Boehr wrote:
>
> > Previously, we required bits 5, 6 and 7 to be zero (0x07 == 0b111). But,
> > as per the principles of operation, bit 5 is ignored in MSCH and bits 0,
>
by ioinst_handle_msch(), adjust the mask accordingly.
>
> Fixes: db1c8f53bfb1 ("s390: Channel I/O basic definitions.")
> Signed-off-by: Nico Boehr
> Reviewed-by: Pierre Morel
> Reviewed-by: Halil Pasic
> Reviewed-by: Janosch Frank
On Wed, 8 Dec 2021 13:56:19 -0500
"Michael S. Tsirkin" wrote:
> On Fri, Nov 12, 2021 at 03:57:44PM +0100, Halil Pasic wrote:
> > This is an early RFC for a transport specific early detecton of
> > modern virtio, which is most relevant for transitional devices on big
&
On Mon, 6 Dec 2021 11:47:55 +
Daniel P. Berrangé wrote:
> On Mon, Dec 06, 2021 at 12:43:12PM +0100, Claudio Imbrenda wrote:
> > On Mon, 6 Dec 2021 11:21:10 +
> > Daniel P. Berrangé wrote:
> >
> > > On Mon, Dec 06, 2021 at 12:06:11PM +0100, Claudio Imbrenda wrote:
> > > > This patch
On Thu, 2 Dec 2021 12:11:38 -0500
Matthew Rosato wrote:
> >
> > What happens if we migrate a VM from old to new QEMU? Won't the guest be
> > able to observe the change?
> >
>
> Yes, technically -- But # itself is not really all that important, it
> is provided from CLP Q PCI FN to be subse
On Tue, 23 Nov 2021 14:13:40 +0100
Halil Pasic wrote:
> On Fri, 12 Nov 2021 15:57:44 +0100
> Halil Pasic wrote:
>
> > This is an early RFC for a transport specific early detecton of
> > modern virtio, which is most relevant for transitional devices on big
> > end
On Fri, 12 Nov 2021 15:57:44 +0100
Halil Pasic wrote:
> This is an early RFC for a transport specific early detecton of
> modern virtio, which is most relevant for transitional devices on big
> endian platforms, when drivers access the config space before
> FEATURES_OK is set.
ap.
>
> Signed-off-by: Christian Borntraeger
Acked-by: Halil Pasic
> ---
> .mailmap| 1 +
> MAINTAINERS | 6 +++---
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/.mailmap b/.mailmap
> index 8beb2f95ae28..c45d1c530144 100644
> ---
On Mon, 15 Nov 2021 17:57:28 +0100
Cornelia Huck wrote:
> On Mon, Nov 15 2021, Halil Pasic wrote:
>
> > On Fri, 12 Nov 2021 16:37:20 +0100
> > Cornelia Huck wrote:
> >
> >> On Fri, Nov 12 2021, Halil Pasic wrote:
> >>
> >> > Lega
On Fri, 12 Nov 2021 16:37:20 +0100
Cornelia Huck wrote:
> On Fri, Nov 12 2021, Halil Pasic wrote:
>
> > Legacy vs modern should be detected via transport specific means. We
> > can't wait till feature negotiation is done. Let us introduce
> > virtio_force_modern()
On Fri, 12 Nov 2021 16:55:10 +0100
Cornelia Huck wrote:
> On Fri, Nov 12 2021, Halil Pasic wrote:
>
> > On Fri, 29 Oct 2021 16:53:25 +0200
> > Cornelia Huck wrote:
> >
> >> On Fri, Oct 29 2021, Halil Pasic wrote:
> >>
> >> > Lega
On Fri, 29 Oct 2021 16:53:25 +0200
Cornelia Huck wrote:
> On Fri, Oct 29 2021, Halil Pasic wrote:
>
> > Legacy vs modern should be detected via transport specific means. We
> > can't wait till feature negotiation is done. Let us introduce
> > virtio_force_modern()
lback is added for the situations where the device needs
to do more than just setting the VIRTIO_F_VERSION_1 feature bit. For
example, when vhost is involved, we may need to propagate the features
to the vhost device.
Signed-off-by: Halil Pasic
---
I'm still struggling with how to deal with
tting FEATURES_OK).
Signed-off-by: Halil Pasic
---
hw/virtio/vhost.c | 17 +
include/hw/virtio/vhost.h | 2 ++
2 files changed, 19 insertions(+)
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index b4b29413e6..5764970298 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vh
Signed-off-by: Halil Pasic
---
Inspired by virtio_net_set_features() which I don't quite understand.
Why do we have to do vhost_net_ack_features() for each possible queue?
---
hw/net/virtio-net.c | 20
1 file changed, 20 insertions(+)
diff --git a/hw/net/virtio-net.c
Let us detect usage via the modern interface by tapping into the place
that implements the 'modern' reset.
Signed-off-by: Halil Pasic
---
hw/virtio/virtio-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 6e16e2705c..
anness starts working as it should for devices that comply to the
virtio spec.
Signed-off-by: Halil Pasic
---
hw/s390x/virtio-ccw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 6a2df1c1e9..88fbe87942 100644
--- a/hw/s390x/virtio-ccw.c
++
tups.
v1 -> v2:
* add callback
* tweak feature manipulation
* add generic handling for vhost that needs to be called by devices
* add handling for virtio
Halil Pasic (5):
virtio: introduce virtio_force_modern()
virtio-ccw: use virtio_force_modern()
virtio-pci: use virtio_force_modern()
On Fri, 5 Nov 2021 03:42:33 -0400
"Michael S. Tsirkin" wrote:
> > This series was only lightly tested.
>
> I think it's a good enough approach, and we are getting close
> to release. For vhost - a new callback just for that? Would be ok.
> Or just invoke set features - if this works.
As of t
Let us detect usage via the modern interface by tapping into the place
that implements the 'modern' reset.
Signed-off-by: Halil Pasic
---
hw/virtio/virtio-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 6e16e2705c..
anness starts working as it should for devices that comply to the
virtio spec.
Signed-off-by: Halil Pasic
---
hw/s390x/virtio-ccw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 6a2df1c1e9..88fbe87942 100644
--- a/hw/s390x/virtio-ccw.c
++
ff-by: Halil Pasic
---
I'm still struggling with how to deal with vhost-user and co. The
problem is that I'm not very familiar with the life-cycle of, let us
say, a vhost_user device.
Looks to me like the vhost part might be just an implementation detail,
and could even become a hot
in the situation described in the previous paragraph, when the
config is managed by a vhost device (and thus outside QEMU).
This series was only lightly tested.
Halil Pasic (3):
virtio: introduce virtio_force_modern()
virtio-ccw: use virtio_force_modern
virtio-pci: use virtio_force_modern
1 - 100 of 1037 matches
Mail list logo
