Virtualization - Jan 2015 - [PATCH RFC v6 13/20] virtio: allow to fail setting status

On Wed, Jan 07, 2015 at 05:13:32PM +0100, Cornelia Huck
wrote:
> On Tue, 30 Dec 2014 14:25:37 +0200
> "Michael S. Tsirkin" <mst at redhat.com> wrote:
> 
> > On Thu, Dec 11, 2014 at 02:25:15PM +0100, Cornelia Huck wrote:
> > > virtio-1 allow setting of the FEATURES_OK status bit to fail if
> > > the negotiated feature bits are inconsistent: let's fail
> > > virtio_set_status() in that case and update virtio-ccw to post an
> > > error to the guest.
> > > 
> > > Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com>
> > 
> > Right but a separate validate_features call is awkward.
> > How about we defer virtio_set_features until FEATURES_OK,
> > and teach virtio_set_features that it can fail?
> 
> Hm. But we would need to keep virtio_set_features() where it is called
> now for legacy devices, as they will never see FEATURES_OK, right?
> So
> we need to make this depending on revisions (or whatever the equivalent
> is for pci/mmio), as we cannot check for VERSION_1. Not sure whether
> this makes the code easier to follow.
So let's make this a separate callback then.
virtio_legacy_set_features?

On Wed, 7 Jan 2015 21:08:21 +0200
"Michael S. Tsirkin" <mst at redhat.com> wrote:
> On Wed, Jan 07, 2015 at 05:13:32PM +0100, Cornelia Huck wrote:
> > On Tue, 30 Dec 2014 14:25:37 +0200
> > "Michael S. Tsirkin" <mst at redhat.com> wrote:
> > 
> > > On Thu, Dec 11, 2014 at 02:25:15PM +0100, Cornelia Huck wrote:
> > > > virtio-1 allow setting of the FEATURES_OK status bit to fail
if
> > > > the negotiated feature bits are inconsistent: let's fail
> > > > virtio_set_status() in that case and update virtio-ccw to
post an
> > > > error to the guest.
> > > > 
> > > > Signed-off-by: Cornelia Huck <cornelia.huck at
de.ibm.com>
> > > 
> > > Right but a separate validate_features call is awkward.
> > > How about we defer virtio_set_features until FEATURES_OK,
> > > and teach virtio_set_features that it can fail?
> > 
> > Hm. But we would need to keep virtio_set_features() where it is called
> > now for legacy devices, as they will never see FEATURES_OK, right?
> > So
> > we need to make this depending on revisions (or whatever the
equivalent
> > is for pci/mmio), as we cannot check for VERSION_1. Not sure whether
> > this makes the code easier to follow.
> 
> So let's make this a separate callback then.
> virtio_legacy_set_features?
I'm not sure I like that. We'd need to touch every transport, right?

On Thu, Jan 08, 2015 at 08:20:37AM +0100, Cornelia Huck
wrote:
> On Wed, 7 Jan 2015 21:08:21 +0200
> "Michael S. Tsirkin" <mst at redhat.com> wrote:
> 
> > On Wed, Jan 07, 2015 at 05:13:32PM +0100, Cornelia Huck wrote:
> > > On Tue, 30 Dec 2014 14:25:37 +0200
> > > "Michael S. Tsirkin" <mst at redhat.com> wrote:
> > > 
> > > > On Thu, Dec 11, 2014 at 02:25:15PM +0100, Cornelia Huck
wrote:
> > > > > virtio-1 allow setting of the FEATURES_OK status bit to
fail if
> > > > > the negotiated feature bits are inconsistent: let's
fail
> > > > > virtio_set_status() in that case and update virtio-ccw
to post an
> > > > > error to the guest.
> > > > > 
> > > > > Signed-off-by: Cornelia Huck <cornelia.huck at
de.ibm.com>
> > > > 
> > > > Right but a separate validate_features call is awkward.
> > > > How about we defer virtio_set_features until FEATURES_OK,
> > > > and teach virtio_set_features that it can fail?
> > > 
> > > Hm. But we would need to keep virtio_set_features() where it is
called
> > > now for legacy devices, as they will never see FEATURES_OK,
right?
> > > So
> > > we need to make this depending on revisions (or whatever the
equivalent
> > > is for pci/mmio), as we cannot check for VERSION_1. Not sure
whether
> > > this makes the code easier to follow.
> > 
> > So let's make this a separate callback then.
> > virtio_legacy_set_features?
> 
> I'm not sure I like that. We'd need to touch every transport,
right?
Yes but there aren't so many.