OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.

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

> 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 ;-)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]