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

[Rusty Russell <rusty@au1.ibm.com>]

"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Fri, Oct 04, 2013 at 09:14:26AM +0930, Rusty Russell 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.
>> 
>> 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.
>
> Not always though. A new driver can be supplied on floppy/cdrom,
> if you don't bind to the old one, the new one can load
> more or less automatically.
>
> All this is not exactly top priority since people mostly
> will want to use transitional devices.
>
> Except for one user: Anthony actually wanted a way
> to disable old drivers for express devices.
> I'm not sure that's really all that important.

Well, we do have the revision ID for PCI, as you suggested on the call.
By the time non-transitional devices become common, hopefully the old
revision-ID-ignoring drivers will be obsolete.

There's a similar field for mmio.  Cornelia seems quite happy to
avoid non-transitional devices for ccw.

> That's broken: we'll run out of an 8 bit field
> and we'll have problems.

Hmm, PCI also uses an 8 bit field.  I don't think it's going to be a
problem in practice anyway.

Cheers,
Rusty.