From: Halil Pasic <pasic@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
David Hildenbrand <david@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org, Halil Pasic <pasic@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org
Subject: Re: [RFC PATCH v2 1/5] virtio: introduce virtio_force_modern()
Date: Mon, 15 Nov 2021 14:26:05 +0100 [thread overview]
Message-ID: <20211115142605.44f452aa.pasic@linux.ibm.com> (raw)
In-Reply-To: <877dddmllb.fsf@redhat.com>
On Fri, 12 Nov 2021 16:37:20 +0100
Cornelia Huck <cohuck@redhat.com> wrote:
> On Fri, Nov 12 2021, Halil Pasic <pasic@linux.ibm.com> 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 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(+)
> >
>
> Did you see my feedback in
> https://lore.kernel.org/qemu-devel/87tugzc26y.fsf@redhat.com/? I think
> at least some of it still applies.
>
Sure. My idea was to send out a v2 first which helps us think about the
bigger picture, and then answer that mail. Now I realize I should have
sent the response first, and then the v2 immediately afterwards.
> > 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)
>
> I'd still prefer to call this virtio_indicate_modern: we don't really
> force anything; the driver has simply already decided that it will use
> the modern interface and we provide an early indication in the features
> so that code looking at them makes the right decisions.
I tried to explain my dislike for virtio_indicate_modern in my response
to that email. In somewhat different words: IMHO indication is about an
external observer and has a symbolic dimension to it. Please see
https://www.oxfordlearnersdictionaries.com/definition/english/indicate
This function is about changing the behavior of the device. Its
post-condition is: the device acts compliant to virtio 1.0 or higher.
>
> > +{
> > + 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);
>
> I don't think this is substantially different from setting VERSION_1
> only: At least the callers you introduce call this during reset,
> i.e. when guest_features is 0 anyway.
I agree. Just wanted to be conservative, and preserve whatever is there.
> We still have the whole processing
> that is done after feature setting that may have effects different from
> what the ultimate feature setting will give us.
Yes, this is an intermediate state. As I pointed out, intermediate states
are necessary.
> While I don't think
> calling set_features twice is forbidden, that sequence is likely quite
> untested, and I'm not sure we can exclude side effects.
I can't disagree with that. But IMHO we can just say: such problems, if
any, are bugs that need to be fixed.
I think not doing the whole song-and-dance is conceptually more
problematic because it is more likely to lead to inconsistent internal
state. For example check out: vhost acked_features <-> guest_features.
Regards,
Halil
>
> > + /* 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
>
>
next prev parent reply other threads:[~2021-11-15 13:29 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 ` [RFC PATCH v2 1/5] virtio: introduce virtio_force_modern() Halil Pasic
2021-11-12 15:37 ` Cornelia Huck
2021-11-15 13:26 ` Halil Pasic [this message]
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=20211115142605.44f452aa.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).