Re: [virtio] Groups - Action Item "Create text version of virtio 0.9.5 document" added

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jul 31, 2013 at 01:25:41PM +0100, Pawel Moll wrote:
> On Wed, 2013-07-31 at 12:43 +0100, Michael S. Tsirkin wrote:
> > On Wed, Jul 31, 2013 at 12:05:07PM +0100, Pawel Moll wrote:
> > > On Wed, 2013-07-31 at 11:29 +0100, Michael S. Tsirkin wrote:
> > > >  Em, which one of specs? What I'm talking about is reserving a "Subsystem
> > > > > Device ID" (p.2.1 of the current spec) value 0 to a "device that does
> > > > > nothing" (is not a network card, nor block device, nor console, nor etc.
> > > > > nor anything else) and specifying how is the guest supposed to behave
> > > > > with such device (do nothing). In the current speech it would be
> > > > > "Appendix I: Doing Nothing Device", following "Appendix I: SCSI Host
> > > > > Device". How does this break anything?
> > > > 
> > > > It doesn't but then it will have to keep doing nothing :)
> > > 
> > > And that's the general plan.
> > 
> > Confused. You wrote: usecase:
> > 	create a pool of memory
> > 	mapped devices and assign functions to them later
> > Sounds like you really want a way to say
> > "there's no device there" not "there's a device here but it does nothing".
> 
> Hm. Qemu people can't say "there's no device there", so they wanted to
> define a set of "devices doing nothing" as a default (at well known
> addresses, so the guest OS knows exactly where to look for virtio
> devices) and sometimes make some of them do something depending on the
> command line options. All this *before* the OS is actually launched, so
> when this happens the landscape is already set, eg. either 4 do-nothing
> devices, or 3 do-nothings and one block device, or 2 do-nothings, one
> block, one network device, etc.
> 
> Of course you can argue that they should go back and redesign Qemu (this
> problem pretty much boils down to the way they generate Device Trees).
> Maybe they should, but I really really don't see anything wrong with
> providing them this little courtesy.

So is this an intermediate configuration guest never sees?
In that case why is anything at all required in the spec?


> > Many buses have device presence detection built-in.
> > Many have hotplug support. If a bus doesn't have these you
> > have to design something device specific but I don't think
> > it makes sense to add this overhead for buses that do.
> 
> What kind of overhead do you mean? I see completely no overhead for
> anyone. Any example where would it have an impact on the PCI
> implementation?

Hard to say since you didn't send a patch.
Basically are you adding a new device with ID 0
for all buses?

In practice in PCI we use same device ID and
subsystem device ID. Here we'll have to come up
with some special ID just for that. Not good, better
to use ID from a standard range.


> > > But seriously speaking, I'm just trying to formalize the current
> > > behaviour of the core. Today it does nothing if there is no driver for a
> > > particular VIRTIO_ID_*, and there is no (and will never be) driver with
> > > 0 in id_table.
> > 
> > The core might not do anything, but the OS does (e.g. prompt for
> > a driver).
> >
> > Basically spec describes what Linux virtio does, but it's
> > not possible to support what spec describes (match all
> > device IDs, use subsystem ID to select the driver) on all OS-es.
> > So we need to fix this part of spec, not build upon this bug
> > to add more features that not all guests will be able to support.
> 
> Now it's me who is confused. At some point the bus-specific
> implementation (mmio, PCI, ccw) does
> 
> 		...(struct virtio_device).id.device = <value>
> 
> or
> 		(equivalent in other OS)
> 
> and than the virtio-core (or equivalent in other OS) makes some further
> decision based on the <value>.
>
> I want to make sure that if the <value> == 0, the core will not even try
> to look for a driver for such device. I think any OS can support such
> "feature".
>
> Or maybe I'm missing some fundamental problem (what would it be) or we
> are simply talking about different things?
> 
> Paweł

I'm confused by you discussing "core" here. We are talking
about driver/device interface right? This is what
the spec describes.

So some buses don't allow ID 0, and some OSes switch to
strange failure modes if you specify device without
a driver. Some OSes and buses have standard ways to detect
device presence and report it to OS.
So we can insert text that requires handling ID 0
in virtio-mmio appendix which is bus specifix and
appears to be somewhat linux specific.


> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php