From: Halil Pasic <pasic@linux.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-s390@vger.kernel.org, markver@us.ibm.com,
Christian Borntraeger <borntraeger@de.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Halil Pasic <pasic@linux.ibm.com>,
Xie Yongji <xieyongji@bytedance.com>
Subject: Re: [RFC PATCH 1/1] virtio: write back features before verify
Date: Sun, 3 Oct 2021 07:00:30 +0200 [thread overview]
Message-ID: <20211003070030.658fc94e.pasic@linux.ibm.com> (raw)
In-Reply-To: <20211002141351-mutt-send-email-mst@kernel.org>
On Sat, 2 Oct 2021 14:20:47 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >From my perspective the problem is that the version of the device
> > remains in limbo as long as the features have not yet been finalized,
> > which means that the endianness of the config space remains in limbo as
> > well. Both device and driver might come to different conclusions.
>
> Version === legacy versus modern?
> It is true that feature negotiation can not be used by device to decide that
> question simply because it happens too late.
> So let's not use it for that then ;)
>
> Yes we have VERSION_1 which looks like it should allow this, but
> unfortunately it only helps with that for the driver, not the device.
>
> In practice legacy versus modern has to be determined by
> transport specific versioning, luckily we have that for all
> specified transports (can't say what happens with rproc).
So if we look at ccw, you say that the revision negotiation already
determines whether VERSION_1 is negotiated or not, and the
feature bit VERSION_1 is superfluous?
That would also imply, that
1) if revision > 0 was negotiated then the device must offer VERSION_1
2) if revision > 0 was negotiated and the driver cleared VERSION_1
the device must refuse to operate.
3) if revision > 0 was negotiated then the driver should reject
to drive a device if it does not offer VERSION_1
4) if revision > 0 was negotiated the driver must accept VERSION_1
5) if revision > 0 was *not* negotiated then the device should not offer
VERSION_1 because at this point it is already certain that the device
can not act in accordance to the virtio 1.0 or higher interface.
Does that sound about right?
IMHO we should also change
https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-160003
and the definition of VERSION_1 because both sides have to know what is
going on before features are fully negotiated. Or?
Regards,
Halil
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-10-03 5:00 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-30 1:20 [RFC PATCH 1/1] virtio: write back features before verify Halil Pasic
2021-09-30 8:04 ` Christian Borntraeger
2021-09-30 9:28 ` Cornelia Huck
2021-09-30 11:03 ` Halil Pasic
2021-09-30 11:31 ` Cornelia Huck
2021-10-01 14:22 ` Halil Pasic
2021-10-01 15:18 ` Cornelia Huck
2021-10-02 18:13 ` Michael S. Tsirkin
2021-10-04 2:23 ` Halil Pasic
2021-10-04 9:07 ` Michael S. Tsirkin
2021-10-05 10:06 ` Cornelia Huck
2021-10-05 10:43 ` Halil Pasic
2021-10-05 11:11 ` Michael S. Tsirkin
2021-10-05 11:13 ` Cornelia Huck
2021-10-05 11:20 ` Michael S. Tsirkin
2021-10-05 11:59 ` Halil Pasic
2021-10-05 15:25 ` Cornelia Huck
2021-10-04 7:01 ` Cornelia Huck
2021-10-04 9:25 ` Halil Pasic
2021-10-04 9:51 ` Cornelia Huck
2021-10-02 12:09 ` Michael S. Tsirkin
2021-09-30 11:12 ` Michael S. Tsirkin
2021-09-30 11:36 ` Cornelia Huck
2021-10-02 18:20 ` Michael S. Tsirkin
2021-10-03 5:00 ` Halil Pasic [this message]
2021-10-03 6:42 ` Michael S. Tsirkin
2021-10-03 7:26 ` Michael S. Tsirkin
2021-10-04 12:01 ` Cornelia Huck
2021-10-04 12:54 ` Michael S. Tsirkin
2021-10-04 14:27 ` Cornelia Huck
2021-10-04 15:05 ` Michael S. Tsirkin
2021-10-04 15:45 ` [virtio-dev] " Cornelia Huck
2021-10-04 20:01 ` Michael S. Tsirkin
2021-10-05 7:38 ` Cornelia Huck
2021-10-05 11:17 ` Halil Pasic
2021-10-05 11:22 ` Michael S. Tsirkin
2021-10-05 15:20 ` Cornelia Huck
2021-10-01 7:21 ` Halil Pasic
2021-10-02 10:21 ` Michael S. Tsirkin
2021-10-04 12:19 ` Cornelia Huck
2021-10-04 13:11 ` Michael S. Tsirkin
2021-10-04 14:33 ` Cornelia Huck
2021-10-04 15:07 ` Michael S. Tsirkin
2021-10-04 15:50 ` Cornelia Huck
2021-10-04 19:17 ` Michael S. Tsirkin
2021-10-06 10:13 ` Cornelia Huck
2021-10-06 12:15 ` Michael S. Tsirkin
2021-10-05 7:25 ` Halil Pasic
2021-10-05 7:53 ` Michael S. Tsirkin
2021-10-05 10:46 ` Halil Pasic
2021-10-05 11:11 ` Michael S. Tsirkin
2021-10-01 14:34 ` Christian Borntraeger
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=20211003070030.658fc94e.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=markver@us.ibm.com \
--cc=mst@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xieyongji@bytedance.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).