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 13:57 +0100, Michael S. Tsirkin wrote:
> > 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?

Because eventually there will be always 4 devices seen by the guest. And
how do you make all of them do nothing in a universal way?

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

Ok, are you saying that pci_dev->subsystem_device must no be 0? If so,
would

#define VIRTIO_ID_NULL 42 /* or _NOP or _DUMMY */

(the value has been chosen semi-randomly ;-) be better? I'm talking
about 0 because I never expected it to have any side-effects.

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

Yes, but to my mind the virtio devices (block, network etc.) constitute
their own bus with driver/device interface, which is independent of the
underlying physical bus (being PCI, mmio etc.). And what I propose is to
make one ID special

> So some buses don't allow ID 0, and some OSes switch to
> strange failure modes if you specify device without
> a driver. 

Are you saying that the existence of (let's just pick an example)
VIRTIO_ID_RPROC_SERIAL ID is a problem, because not all OSes will
implement it? 

> Some OSes and buses have standard ways to detect
> device presence and report it to OS.

Ok, so I treat VIRTIO_ID_* values (include/uapi/linux/virtio_ids.h) as
bus-independent. If you're saying that 0 will be a problem for PCI, I'm
perfectly happy to use 13 (currently the next available number) or any
other value, really. 0 seemed the most natural choice, but nothing more
than this.

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

The list of IDs is not in the mmio appendix. And I hope that the OASIS
spec will not make PCI implementation in anyway privileged over mmio,
thus both will use the same abstract list of *virtio device* IDs. Which
is maybe what you meant by "fixing the spec" in the first place?

Paweł