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 02:33:51PM +0100, Pawel Moll wrote:
> 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?

okay so that's something very virtio-mmio specific, isn't it?

> > > 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 */

If we need this device, just use the next free number. 13 isn't it?
But see below.

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

That's hardly universal.  At least from the spec and guest/host
interface perspective, there's no virtio bus.

Linux drivers have their own bus mostly because it's so easy
in Linux, but it's messier in windows so they don't do this.

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

OS-es that trigger errors/warnings on unknown devices will have to at
least add a stub driver to avoid these errors.
So there's cost associated with adding more device IDs
for all buses, there should be some benefit.

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

For now we are using PCI IDs for enumeration. So we better make sure
they are legal PCI IDs.
virtio PCI is used by many non linux guests. This makes us worry more about
compatibility and legacy with respect to virtio PCI. It's different, I'm
not sure I would call it "priveledged" :)

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

I meant using standard bus specific things where we are describing bus
specific behaviour.
In this case, I think you really want a "no device" flag for
virtio-mmio which originally lacked device presence detection.
I think for this purpose, it is best to to:

1. declare device ID 0 (or e.g. FFFF) as reserved and illegal for devices,
   explicitly in core spec
2. in the mmio appendix, say that if ID 0 (or FFFF) is detected, this
   means device not present


I think this is the cleaner approach than saying there's
a dummy "null device" in particular because

1. there won't be dummy devices on the bus, in sysfs etc
2. down the road you will be able to support hotplug.


-- 
MST