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
ly support 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't
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
> >&
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)
>
: split out s390x sections")
> Signed-off-by: Eric Farman
Reviewed-by: Halil Pasic
> qemu_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
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
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
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
> >>>
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
that is only the case for the default configuration of QEMU's s390x
> target.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Halil Pasic
TM
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
> + * HOST_BIG_END
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
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_PLAT
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:
* Rebas
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
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 not
on 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/avocado
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
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
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:
* Twe
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
unsupporte
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
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 the con
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
unsupporte
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
> >
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(vde
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(>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
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.
, 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, but
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.
> >
> > @Br
+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
> > is
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
, 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, but
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 w
ondition 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!
Signed-off-b
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
Ac
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
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
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
oinst_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
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() as a
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() as a
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 vhost-user
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/vhost.c
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 b/hw
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..8dd862da21
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
++
-> 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()
vhost: p
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
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..8dd862da21
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
++
-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 swappable thing
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
On Wed, 13 Oct 2021 08:24:53 -0400
"Michael S. Tsirkin" wrote:
> > > OK this looks good! How about a QEMU patch to make it spec compliant on
> > > BE?
> >
> > Who is going to do that? Halil? you? Conny?
>
> Halil said he'll do it... Right, Halil?
I can do it but not right away. Maybe in a
On Tue, 12 Oct 2021 16:40:39 +0200
Cornelia Huck wrote:
> I'm no longer involved with KVM/s390 on the kernel side, and I don't
> have enough resources to work on the s390 KVM cpus support, so I'll
> step down.
>
> Signed-off-by: Cornelia Huck
Acked-by: Halil Pasic
Tha
On Tue, 12 Oct 2021 16:40:40 +0200
Cornelia Huck wrote:
> I currently don't have time to work on the s390x virtio-ccw machine
> anymore, so let's step down. (I will, however, continue as a
> maintainer for the virtio-ccw *transport*.)
>
> Signed-off-by: Cornelia Huck
Acked-
, so at least that's not a regression.
No devices except virtio net and virtio blk seem to be affected.
Long term the right thing to do is to fix the hypervisors.
Cc: #v4.11
Signed-off-by: Halil Pasic
Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config
space")
Fi
On Fri, 8 Oct 2021 09:05:03 -0400
"Michael S. Tsirkin" wrote:
> On Fri, Oct 08, 2021 at 02:34:22PM +0200, Halil Pasic wrote:
> > The virtio specification virtio-v1.1-cs01 states: "Transitional devices
> > MUST detect Legacy drivers by detecting that VIRTI
atter renders virtio-blk unusable
with DASD backing, because things simply don't work with the default.
Cc: #v4.11
Signed-off-by: Halil Pasic
Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config
space")
Fixes: fe36cbe0671e ("virtio_net: clear MTU wh
On Thu, 07 Oct 2021 17:25:52 +0200
Cornelia Huck wrote:
> On Thu, Oct 07 2021, Halil Pasic wrote:
>
> > On Thu, 07 Oct 2021 13:52:24 +0200
> > Cornelia Huck wrote:
> >
> >> On Wed, Oct 06 2021, Halil Pasic wrote:
> >>
> >>
On Thu, 07 Oct 2021 13:52:24 +0200
Cornelia Huck wrote:
> On Wed, Oct 06 2021, Halil Pasic wrote:
>
> > The virtio specification virtio-v1.1-cs01 states: Transitional devices
> > MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not
> > been ac
negotiation
is complete. However, we already have regression so let's try to address
it.
Signed-off-by: Halil Pasic
Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config
space")
Fixes: fe36cbe0671e ("virtio_net: clear MTU when out of range")
Reported-by
On Tue, 05 Oct 2021 13:13:31 +0200
Cornelia Huck wrote:
> On Tue, Oct 05 2021, Halil Pasic wrote:
>
> > On Mon, 4 Oct 2021 05:07:13 -0400
> > "Michael S. Tsirkin" wrote:
> >> Well we established that we can know. Here's an alternative explanation:
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.
1 - 100 of 1020 matches
Mail list logo
