All of lore.kernel.org
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	 Halil Pasic <pasic@linux.ibm.com>,
	qemu-s390x@nongnu.org, qemu-devel@nongnu.org
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	Thomas Huth <thuth@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	David Hildenbrand <david@redhat.com>
Subject: [RFC PATCH v2 1/5] virtio: introduce virtio_force_modern()
Date: Fri, 12 Nov 2021 15:57:45 +0100	[thread overview]
Message-ID: <20211112145749.618157-2-pasic@linux.ibm.com> (raw)
In-Reply-To: <20211112145749.618157-1-pasic@linux.ibm.com>

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 means for the transport code to signal
that the device should operate in modern mode (because a modern driver
was detected).

A new callback 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 <pasic@linux.ibm.com>
---

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.

Another thing is, that vhost processes set_features differently. It
might or might not be a good idea to change this.

Does anybody know why don't we propagate the features on features_set,
but under a set of different conditions, one of which is the vhost
device is started?
---
 hw/virtio/virtio.c         | 13 +++++++++++++
 include/hw/virtio/virtio.h |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 3a1f6c520c..26db1b31e6 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -3281,6 +3281,19 @@ void virtio_init(VirtIODevice *vdev, const char *name,
     vdev->use_guest_notifier_mask = true;
 }
 
+void  virtio_force_modern(VirtIODevice *vdev)
+{
+    VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
+
+    virtio_add_feature(&vdev->guest_features, VIRTIO_F_VERSION_1);
+    /* Let the device do it's normal thing. */
+    virtio_set_features(vdev, vdev->guest_features);
+    /* For example for vhost-user we have to propagate to the vhost dev. */
+    if (k->force_modern) {
+        k->force_modern(vdev);
+    }
+}
+
 /*
  * Only devices that have already been around prior to defining the virtio
  * standard support legacy mode; this includes devices not specified in the
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 8bab9cfb75..1bb1551865 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -126,6 +126,7 @@ struct VirtioDeviceClass {
     int (*validate_features)(VirtIODevice *vdev);
     void (*get_config)(VirtIODevice *vdev, uint8_t *config);
     void (*set_config)(VirtIODevice *vdev, const uint8_t *config);
+    void (*force_modern)(VirtIODevice *vdev);
     void (*reset)(VirtIODevice *vdev);
     void (*set_status)(VirtIODevice *vdev, uint8_t val);
     /* For transitional devices, this is a bitmap of features
@@ -394,6 +395,7 @@ static inline bool virtio_device_disabled(VirtIODevice *vdev)
     return unlikely(vdev->disabled || vdev->broken);
 }
 
+void  virtio_force_modern(VirtIODevice *vdev);
 bool virtio_legacy_allowed(VirtIODevice *vdev);
 bool virtio_legacy_check_disabled(VirtIODevice *vdev);
 
-- 
2.25.1



  reply	other threads:[~2021-11-12 15:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-12 14:57 [RFC PATCH v2 0/5] virtio: early detect 'modern' virtio Halil Pasic
2021-11-12 14:57 ` Halil Pasic [this message]
2021-11-12 15:37   ` [RFC PATCH v2 1/5] virtio: introduce virtio_force_modern() Cornelia Huck
2021-11-15 13:26     ` Halil Pasic
2021-11-15 16:57       ` Cornelia Huck
2021-11-16 14:44         ` Halil Pasic
2021-11-12 14:57 ` [RFC PATCH v2 2/5] virtio-ccw: use virtio_force_modern() Halil Pasic
2021-11-12 14:57 ` [RFC PATCH v2 3/5] virtio-pci: " Halil Pasic
2021-11-12 14:57 ` [RFC PATCH v2 4/5] vhost: push features to backend on force_modern Halil Pasic
2021-11-12 14:57 ` [RFC PATCH v2 5/5] virtio-net: handle force_modern for vhost Halil Pasic
2021-11-23 13:13 ` [RFC PATCH v2 0/5] virtio: early detect 'modern' virtio Halil Pasic
2021-11-29 11:59   ` Halil Pasic
2021-12-08 18:56 ` Michael S. Tsirkin
2021-12-09 13:29   ` Halil Pasic
2021-12-09 17:54     ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211112145749.618157-2-pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.