"Michael S. Tsirkin" <> writes:
> On Thu, Sep 19, 2013 at 11:53:24AM +0930, Rusty Russell wrote:
>> We should also define what "locks in" feature negotiation: that was
>> simple for single 32-bit field. Should we define this in a
>> transport-independent way, or leave it to the transports?
>>
>> We could overload the DRIVER status bit (which Linux currently calls too
>> early, though moving it would be harmless), or add a new one.
>
> I'm surprised.
> I always read 2.2.1. Device Initialization as
> an explicit requirement that DRIVER_OK locks the features,
> and that's in a transport-independent section and
> works for existing guests.
>
> And if that's not explicit enough, would the proposed
> resolution for VIRTIO-30 make it explicit enough?
Linux violates this, as it makes the device live *then* sets DRIVER_OK.
This means we can use the device (and *do*, for virtio_blk partition
scanning) before finalizing features.
We could become compliant by setting DRIVER_OK before calling the
driver, but that's be misleading: we'd not expect DRIVER_OK if the
driver init failed.
So I think we will need a new bit, FEATURES_OK?
Cheers,
Rusty.
