Re: [virtio-dev] [PATCH] transitional issues: add new IDs for all devices

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Fri, 04 Oct 2013 09:14:26 +0930
Rusty Russell <rusty@au1.ibm.com> wrote:

> "Michael S. Tsirkin" <mst@redhat.com> writes:
> > On Wed, Oct 02, 2013 at 08:20:33AM +0300, Michael S. Tsirkin wrote:
> >> On Wed, Oct 02, 2013 at 10:02:28AM +0930, Rusty Russell wrote:
> >> > "Michael S. Tsirkin" <mst@redhat.com> writes:
> >> > > On Thu, Sep 26, 2013 at 11:35:53AM +0930, Rusty Russell wrote:
> >> > >> How about a PCI note something like:
> >> > >> 
> >> > >>         If a device does not support legacy mode, and is on a platform
> >> > >>         where a legacy device with the same ID has previously existed,
> >> > >>         it MUST take the following steps to fail gracefully when a
> >> > >>         legacy driver attempts to drive it:
> >> > >> 
> >> > >>         1) Present no I/O BAR, and no BAR 0, OR
> >> > >>         2) Respond to a single-byte zero write to offset 18 of any I/O
> >> > >>            BAR or BAR0 by presenting zeroes on every BAR and ignoring
> >> > >>            writes.
> >> > >> 
> >> > >> This means it presents 0 virtqueues; at the very least, it makes the
> >> > >> device harmless.
> >> > >> 
> >> > >> Note that I didn't specify that it should only be the first write: think
> >> > >> of the kexec case, where an OS crash causes an older OS to come in and
> >> > >> try to reset the device...
> >> > >> 
> >> > >> Would that work?
> >> > >> Rusty.
> >> > >
> >> > > So I guess we can also suggest revision id > 0 for pci
> >> > > and > 1 for mmio for non transitional devices.
> >> > 
> >> > Only if mmio changes its layout in an incompatible way: that's not
> >> > confimed yet.  Otherwise there's no reason to worry about older drivers
> >> > as the device can fail gracefully when feature 32 isn't acknowledged.
> >> > 
> >> > > At least with recent windows drivers, this will be enough
> >> > > to not make them bind, and it will also work for
> >> > > linux drivers.
> >> > >
> >> > > Question: what to do if we want do create a non transitional
> >> > > device on ccw?
> >> > 
> >> > I think they're happy with their current layout, but I leave this to
> >> > Cornelia (CC'd, but she's still away).
> >> > 
> >> > Cheers,
> >> > Rusty.
> >> 
> >> Well this means they aren't interested in addressing
> >> https://tools.oasis-open.org/issues/browse/VIRTIO-40
> >> ?
> >> Also, endian-ness change if it goes through is enough to
> >> break drivers in weird ways, isn't it?
> >
> > Also, changes like driver initialization change also
> > make for a bunch of interesting bugs.
> > If we let legacy drivers bind to non transitional
> > devices, that just makes for a bunch of weird issues
> > to consider.

I currently don't see any need for non-transitional devices. If we want
to do these later on, I'd probably want to handle them via a new 'set
virtio revision' channel command, as I had thought out loud earlier.
This would also fence off non-transitional devices from legacy drivers.

> 
> Well, the main issue is that it simply won't work.  Your guest without a
> network or block device or console is usually a useless guest.
> 
> We should think through these issues for each transport, to make sure
> they handle this case like I suggested for PCI, but I don't think it's
> impossible.

I'll have to read up on your suggestions.

> 
> Cheers,
> Rusty.