Virtualization - Nov 2014 - [PATCH RFC v4 00/16] qemu: towards virtio-1 host support

On Thu, 27 Nov 2014 17:42:11 +0200
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> On Thu, Nov 27, 2014 at 04:31:39PM +0100, Cornelia Huck wrote:
> > On Thu, 27 Nov 2014 17:24:22 +0200
> > "Michael S. Tsirkin" <mst at redhat.com> wrote:
> > 
> > > On Thu, Nov 27, 2014 at 04:16:33PM +0100, Cornelia Huck wrote:
> > > > Yet another version of the virtio-1 support patches.
> > > > 
> > > > This one has seen some (very) light testing with the
virtio-1 guest
> > > > support patches currently on vhost-next.
> > > > 
> > > > Changes from v3:
> > > > 
> > > > - Add support for FEATURES_OK. We refuse to set features
after the
> > > >   driver has set this in the status field, and we allow to
fail
> > > >   setting the status if the features are inconsistent.
> > > > - Add missing virtio-1 changes for virtio-net (header size
and mac).
> > > > - Dropped setting the VERSION_1 bit for virtio-blk:
There's still
> > > >   some stuff missing.
> > > > 
> > > > For virtio-blk, we need to validate the feature bits if
version 1 is
> > > > negotiated: some legacy features are not allowed in that
case. I'm not
> > > > quite sure how to handle this, though. We could use the new
> > > > validate_features callback to verify that the driver
negotiated a
> > > > sensible feature set, but that would require us to offer a
superset
> > > > of legacy and version 1 bits, which feels wrong. Any ideas?
> > > 
> > > No, that's violating the spec.
> > > I think the simplest way is to have separate features and
> > > legacy_features fields.  Present the correct one depending on
which
> > > revision was negotiated.
> > 
> > But revisions are a virtio-ccw only thing - what can other transports
> > do here?
> 
> Other transports have different ways to deal with this.
> For example virtio pci exposes a legacy header and
> a modern header. Legacy header will expose old features,
> modern one - new features.
> 
> mmio simply does not support transitional devices.
> So qemu user will have to specify virtio 1.0 or 0.9 for mmio.
> 
> Other transports are out of virtio 1.0 spec so
> they just use legacy features.
> 
> > The basic problem is that we decide via a feature bit that
> > needs to be negotiated which feature bits we want to present.
> 
> Consider wce as one example.  This is not needed for modern guests, so
> we can just mask it from modern feature mask.  Consider virtio blk scsi
> commands as another example.  this feature is not supported in virtio
> 1.0, so we must mask it from modern feature mask.
> 
> Seems the same handling works in all cases?
This was just what I was talking about...
> 
> 
> > pci and
> > mmio don't have a way to know whether the driver wants to use 1.0
or
> > legacy prior to feature negotiation, do they?
> 
> pci does. mmio doesn't but it does not want to support transitional
> devices.
> 
So we should have a per-device callback into the transport layer, say
check_legacy()?

For ccw, this would check for the negotiated revision; for mmio, it
could check a device property configured with the device; and for pci,
whatever the mechanism is there :)

A transport not implementing this callback is simply considered
legacy-only.

On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck
wrote:
> On Thu, 27 Nov 2014 17:42:11 +0200
> "Michael S. Tsirkin" <mst at redhat.com> wrote:
> 
> > On Thu, Nov 27, 2014 at 04:31:39PM +0100, Cornelia Huck wrote:
> > > On Thu, 27 Nov 2014 17:24:22 +0200
> > > "Michael S. Tsirkin" <mst at redhat.com> wrote:
> > > 
> > > > On Thu, Nov 27, 2014 at 04:16:33PM +0100, Cornelia Huck
wrote:
> > > > > Yet another version of the virtio-1 support patches.
> > > > > 
> > > > > This one has seen some (very) light testing with the
virtio-1 guest
> > > > > support patches currently on vhost-next.
> > > > > 
> > > > > Changes from v3:
> > > > > 
> > > > > - Add support for FEATURES_OK. We refuse to set
features after the
> > > > >   driver has set this in the status field, and we allow
to fail
> > > > >   setting the status if the features are inconsistent.
> > > > > - Add missing virtio-1 changes for virtio-net (header
size and mac).
> > > > > - Dropped setting the VERSION_1 bit for virtio-blk:
There's still
> > > > >   some stuff missing.
> > > > > 
> > > > > For virtio-blk, we need to validate the feature bits if
version 1 is
> > > > > negotiated: some legacy features are not allowed in
that case. I'm not
> > > > > quite sure how to handle this, though. We could use the
new
> > > > > validate_features callback to verify that the driver
negotiated a
> > > > > sensible feature set, but that would require us to
offer a superset
> > > > > of legacy and version 1 bits, which feels wrong. Any
ideas?
> > > > 
> > > > No, that's violating the spec.
> > > > I think the simplest way is to have separate features and
> > > > legacy_features fields.  Present the correct one depending
on which
> > > > revision was negotiated.
> > > 
> > > But revisions are a virtio-ccw only thing - what can other
transports
> > > do here?
> > 
> > Other transports have different ways to deal with this.
> > For example virtio pci exposes a legacy header and
> > a modern header. Legacy header will expose old features,
> > modern one - new features.
> > 
> > mmio simply does not support transitional devices.
> > So qemu user will have to specify virtio 1.0 or 0.9 for mmio.
> > 
> > Other transports are out of virtio 1.0 spec so
> > they just use legacy features.
> > 
> > > The basic problem is that we decide via a feature bit that
> > > needs to be negotiated which feature bits we want to present.
> > 
> > Consider wce as one example.  This is not needed for modern guests, so
> > we can just mask it from modern feature mask.  Consider virtio blk
scsi
> > commands as another example.  this feature is not supported in virtio
> > 1.0, so we must mask it from modern feature mask.
> > 
> > Seems the same handling works in all cases?
> 
> This was just what I was talking about...
> 
> > 
> > 
> > > pci and
> > > mmio don't have a way to know whether the driver wants to use
1.0 or
> > > legacy prior to feature negotiation, do they?
> > 
> > pci does. mmio doesn't but it does not want to support
transitional
> > devices.
> > 
> 
> So we should have a per-device callback into the transport layer, say
> check_legacy()?
I would just have 2 masks: legacy_features and features.
> For ccw, this would check for the negotiated revision; for mmio, it
> could check a device property configured with the device; and for pci,
> whatever the mechanism is there :)
> 
> A transport not implementing this callback is simply considered
> legacy-only.
I dislike callbacks. Let's just give all info to core,
and have it DTRT.

On Thu, 27 Nov 2014 18:18:25 +0200
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck wrote:
> > So we should have a per-device callback into the transport layer, say
> > check_legacy()?
> 
> I would just have 2 masks: legacy_features and features.
But these belong to the device type and the transport just needs to
trigger usage of the right one, right?
> 
> > For ccw, this would check for the negotiated revision; for mmio, it
> > could check a device property configured with the device; and for pci,
> > whatever the mechanism is there :)
> > 
> > A transport not implementing this callback is simply considered
> > legacy-only.
> 
> I dislike callbacks. Let's just give all info to core,
> and have it DTRT.
> 
Have a is_legacy flag in the vdev that is initialized to 1, and
transports can unset it when the revision is negotiated or during init?