Re: [Qemu-devel] [PATCH 0/4] virtio: Move host features to backends

[Cornelia Huck]

On Mon, 20 Apr 2015 11:12:37 +0200
"Michael S. Tsirkin" <address@hidden> wrote:

> On Mon, Apr 20, 2015 at 10:54:11AM +0200, Cornelia Huck wrote:
> > On Fri, 17 Apr 2015 15:00:45 +0100
> > Peter Maydell <address@hidden> wrote:
> > 
> > > On 17 April 2015 at 14:43, Cornelia Huck <address@hidden> wrote:
> > > > On Fri, 17 Apr 2015 20:13:42 +0800
> > > > Shannon Zhao <address@hidden> wrote:
> > > >
> > > > [Some questions may be silly, but I'm not familiar with the virtio-mmio
> > > > code]
> > > >
> > > >> The reason to do this is that the virtio-net-device can't expose host
> > > >> features to guest while using virtio-mmio. So the performance is low.
> > > >
> > > > So how does virtio-mmio expose any host features?
> > > 
> > > The features are properties of the backend, not the transport.
> > > So for devices where we didn't set these up as "properties
> > > exist on the backend and the compatibility transport+backend
> > > wrapper devices just forward those properties to the backend",
> > > you can't set the properties. We got this right for some of
> > > the backends (eg blk) but not all of them, I think.
> > 
> > The reason why blk is ok is that it adds the feature bits in its
> > ->get_features() callback. net expects the feature bits already present
> > and removes not supported ones and therefore requires
> > statically-defined bits somewhere.
> > 
> > If we move the feature bits to virtio-net and virtio-scsi, it should
> > work for virtio-mmio - but the feature bit propagation from the device
> > into the transport becomes a bit useless.
> > 
> > Could net and scsi add the feature bits dynamically in their
> > ->get_features() callback instead? This should work for virtio-mmio as
> > well afaics.
> > 
> > In the end, we should probably end up with the same mechanism for all
> > device types.
> 
> I think I would also prefer that the host features live in the
> generic virtio device structure. 

You mean in the virtio device instead of the proxy device? I think that
makes sense conceptually, provided we get the realize/plug sequence
correct.

> This would make it possible
> e.g. to validate guest features on vm load in generic code.
> 

Doesn't virtio_load() already do some validation?