From: "Michael S. Tsirkin" <mst@redhat.com>
To: Pawel Moll <pawel.moll@arm.com>
Cc: "virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>
Subject: Re: [RFC] virtio-mmio: Update the device to OASIS spec version
Date: Tue, 20 Jan 2015 19:44:25 +0200 [thread overview]
Message-ID: <20150120174425.GA2706@redhat.com> (raw)
In-Reply-To: <1421774303.14076.19.camel@arm.com>
On Tue, Jan 20, 2015 at 05:18:23PM +0000, Pawel Moll wrote:
> On Mon, 2015-01-19 at 18:36 +0000, Michael S. Tsirkin wrote:
> > > > > Well, not quite: as of now I've got legacy block device driver happily
> > > > > working on top of compliant (so v2 in MMIO speech) MMIO device - the
> > > > > transport if completely transparent here.
> > > >
> > > > Spec says explicitly it's an illegal configuration.
> > >
> > > What part of the spec exactly? The closest I can think of are 2.2.3, 6.2
> > > and 6.3. Both legacy and spec-complaint MMIO transports will satisfy all
> > > requirements from those paragraphs, whether VIRTIO_F_VERSION_1 is
> > > negotiated or not.
> >
> > The parts that say VIRTIO_F_VERSION_1 MUST be set.
> > I'll look up the chapter and verse later if you like.
>
> That would be:
>
> "6.1 Driver Requirements: Reserved Feature Bits
> A driver MUST accept VIRTIO_F_VERSION_1 if it is offered. A driver MAY
> fail to operate further if VIRTIO_F_VERSION_1 is not offered."
>
> "6.2 Device Requirements: Reserved Feature Bits
> A device MUST offer VIRTIO_F_VERSION_1. A device MAY fail to operate
> further if VIRTIO_F_VERSION_1 is not accepted."
That, and there are a bunch of other changes we made in devices
as compared to virtio 0.9.
>
> Both are perfectly clear and reasonable for me. And the MMIO transport
> in both versions (pre-spec and the spec one) will meet those
> requirements, as it was able to pass more than 32 features bits from the
> very beginning.
Good. But your current code will also try to support a mix: device that
uses the new transport underneath, but old layout and semantics on top.
This has no value: the spec does *not* define such devices
and it also does not match any hosts, so this just adds to support matrix.
And if linux supports it, someone *will* ship such a
device and we'll be stuck with it forever.
So please, detect out of spec devices and fail gracefully.
pci and s390 do this already.
> > Can you please also add a comment?
> > E.g.
> > /*
> > * MMIO uses ID 0 to mean device not present. Avoid probing
> > * the device further: it's sure to fail anyway.
> > */
>
> There is a comment:
>
> > On Fri, 2014-12-19 at 18:38 +0000, Pawel Moll wrote:
> > > + /*
> > > + * ID 0 means a dummy (placeholder) device, skip quietly
> > > + * (as in: no error) with no further actions
> > > + */
> >
> But I'm can use your wording if you find it better.
>
> Pawel
Either that or combine them in some way.
next prev parent reply other threads:[~2015-01-20 17:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-19 18:38 [RFC] virtio-mmio: Update the device to OASIS spec version Pawel Moll
2015-01-15 16:51 ` Michael S. Tsirkin
2015-01-15 17:12 ` Michael S. Tsirkin
2015-01-15 17:15 ` Pawel Moll
2015-01-15 17:19 ` Michael S. Tsirkin
2015-01-16 9:58 ` Cornelia Huck
2015-01-15 17:32 ` Pawel Moll
2015-01-15 17:51 ` Michael S. Tsirkin
2015-01-15 18:11 ` Pawel Moll
2015-01-15 18:29 ` Michael S. Tsirkin
2015-01-15 18:42 ` Pawel Moll
2015-01-15 19:12 ` Michael S. Tsirkin
2015-01-19 17:45 ` Pawel Moll
2015-01-19 18:36 ` Michael S. Tsirkin
2015-01-20 17:18 ` Pawel Moll
2015-01-20 17:44 ` Michael S. Tsirkin [this message]
2015-01-20 17:51 ` Pawel Moll
2015-01-20 17:56 ` Michael S. Tsirkin
2015-01-15 18:17 ` Michael S. Tsirkin
2015-01-15 18:39 ` Michael S. Tsirkin
2015-01-15 18:51 ` Pawel Moll
2015-01-15 19:12 ` 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=20150120174425.GA2706@redhat.com \
--to=mst@redhat.com \
--cc=pawel.moll@arm.com \
--cc=virtualization@lists.linux-foundation.org \
/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.