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

[Pawel Moll <pawel.moll@arm.com>]

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.

> 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?

> > 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ł