Re: [virtio] [OASIS Issue Tracker] Created: (VIRTIO-35) race condition with multi-dword config accesses

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Oct 08, 2013 at 06:38:12PM +0100, Pawel Moll wrote:
> On Tue, 2013-10-08 at 14:38 +0100, Michael S. Tsirkin wrote:
> > Well basically what I am saying is that spec should say that drivers
> > MUST support both revision 1 and revision 2 
> 
> No, changing the version number just for the sake of changing it makes
> no sense whatsoever.

It's for the sake of making sure old drivers don't bind
to non transitional devices.

> > MUST always look at the
> > VIRTIO_1 feature bit to check whether device supports the new interface
> > (as opposed to checking the revision).
> 
> The version register has one intention - make the changes of the control
> registers layout (except for the first two of them :-) easy. Sounds like
> this is where we are. No if, buts or guessing - different register
> layout, different version. So that's the transport.
> 
> The feature bit is still required for the functional drivers (block,
> net, scsi etc). Unless I don't understand the idea :-)
> 
> It seems that it would be possible to have a legacy functional device
> with new MMIO control register layout. I'm not sure this would be
> useful, but it should be possible.

I'm sorry I don't understand. We have a set of terms
defined in the spec now- transitional non transitinal legacy.
Can we frame discussion in these terms please?
Changing version makes it a non transitional device.
I am asking for ability to make transitinal
devices as well, this means that
- devices must have ability to have version 1
- drivers must not use version to detect legacy interface

> > This removes info duplication between revision and feature bit
> > and will allow transitional devices if we ever want them
> > after all, without adding complexity.
> 
> Implementation of the transitional devices *will* be more complex than
> ones following one *or* the other version of the spec, I think you can't
> argue that.
> 
> I sympathize with your effort of making the PCI (server) devices/drivers
> backward compatible. But also very *very* strong doubts whether the same
> makes sense in the MMIO world (let's call it "embedded"). I'll make the
> Linux driver work with both kinds of the devices. Other OSes? Don't care
> - I'm 99.9% sure that there are no non-Linux MMIO drivers. Running old
> kernel (legacy driver only) on cutting edge model with new device?
> Tough, I don't think I care either - upgrade the kernel.
> 
> > Is this acceptable to you?
> 
> My acceptance doesn't really matter here - I can be simply voted
> wrong :-) I'm just trying to maintain the MMIO transport's modus
> operandi - keep it simple.
> 
> Anyway, I'll think more about it. Feel free to point out holes in my
> reasoning ;-)
> 
> Paweł
>