[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio] Re: [virtio-dev] [PATCH v3] pci: new configuration layout
On Mon, Sep 23, 2013 at 12:32:48PM +0200, Paolo Bonzini wrote: > Il 23/09/2013 08:26, Michael S. Tsirkin ha scritto: > > On Mon, Sep 23, 2013 at 10:57:24AM +0930, Rusty Russell wrote: > >> "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. > > > > Interesting. > > Actually, e.g. net drivers do this, too: they pre-fill the RX VQs. > > > >> This means we can use the device (and *do*, for virtio_blk partition > >> scanning > > > > What does this refer to? virtblk_getgeo? > > It's done by add_disk (in block/genhd.c). > > Paolo Yes, that's true. Same with most drivers: they expose device to linux as the last step. And there's no clean way to solve this, really. I think devices should buffer kicks received before driver_ok and execute them later. > > That only seems to poke at config space, not VQs. > > > >> ) 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? I would call this more generally, DEVICE_OK. This also means DRIVER_OK must not fail as I proposed for VIRTIO-30. Let's switch to that thread, I'll respond there with a summary of this discussion, and a new proposal. > >> > >> Cheers, > >> Rusty. > > > > But what's the meaning of DRIVER_OK then? > > Maybe it means "device can use VQs"? > > > > And if device does not use VQs, does it matter that > > driver can add buffers there? > > If not maybe we can let driver play with features all > > it wants. > > > > Also all this is really part of discussion for VIRTIO-30 I think? > > It's not really related to the layout - the issue is there > > in old layout as well. > > Correct? > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]