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" <> 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?
> >
