[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 21:59 +0100, Michael S. Tsirkin wrote: > > > 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 You forgot to define what do "device" and "driver" mean then :-P I look at the problem as being divided into the transport interface (driven in Linux by platform_driver virtio_mmio_driver) and the virtio device (driven by struct virtio_driver virtio_blk). Is there any problem with this point of view? Now, the virtio_blk driver can be legacy, transitional or non-transitional. I have no problem with that. MMIO transport is completely transparent in terms of features, including VIRTIO_F_VERSION_1. At the same time virtio_mmio *driver* will be able to drive only version 1 of the transport, only version 2 of the transport or both versions of the transport. The host-side transport implementation will have register layout of version 1 *or* 2 and will *not* change behaviour in runtime depending on VIRTIO_F_VERSION_1. Is there any problem with this? If you prefer I can call version 1 "legacy", and version 2 "non-transitional". I have no problem with this. I believe that with this approach, everything should Just Work (TM). Paweł
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]