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-dev] [PATCH v3] pci: new configuration layout

"Michael S. Tsirkin" <mst@redhat.com> 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?


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