search for: validate_featur

...f 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? > --- > hw/s390x/virtio-ccw.c | 20 ++++++++++++-------- > hw/virtio/virtio.c | 24 +++++++++++++++++++++++- > include/hw/virtio/virtio.h |...

...f 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? > --- > hw/s390x/virtio-ccw.c | 20 ++++++++++++-------- > hw/virtio/virtio.c | 24 +++++++++++++++++++++++- > include/hw/virtio/virtio.h |...

...c b/hw/virtio/virtio.c index a3dd67b..90eedd3 100644 --- a/hw/virtio/virtio.c +++ b/hw/virtio/virtio.c @@ -543,15 +543,37 @@ void virtio_update_irq(VirtIODevice *vdev) virtio_notify_vector(vdev, VIRTIO_NO_VECTOR); } -void virtio_set_status(VirtIODevice *vdev, uint8_t val) +static int virtio_validate_features(VirtIODevice *vdev) +{ + VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev); + + if (k->validate_features) { + return k->validate_features(vdev); + } else { + return 0; + } +} + +int virtio_set_status(VirtIODevice *vdev, uint8_t val) { VirtioDeviceClass *k...

...c b/hw/virtio/virtio.c index a3dd67b..90eedd3 100644 --- a/hw/virtio/virtio.c +++ b/hw/virtio/virtio.c @@ -543,15 +543,37 @@ void virtio_update_irq(VirtIODevice *vdev) virtio_notify_vector(vdev, VIRTIO_NO_VECTOR); } -void virtio_set_status(VirtIODevice *vdev, uint8_t val) +static int virtio_validate_features(VirtIODevice *vdev) +{ + VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev); + + if (k->validate_features) { + return k->validate_features(vdev); + } else { + return 0; + } +} + +int virtio_set_status(VirtIODevice *vdev, uint8_t val) { VirtioDeviceClass *k...

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

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

...'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 featu...

...'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 featu...

...> > > > > > > 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. > > >...

...> > > > > > > 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. > > >...

...l 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 d...

...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...

...l 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 d...

...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...

...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...

...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...

...> > > > 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 s...

...> > > > 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 s...

...ON_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 f...

...; + uint64_t (*get_features_rev)(VirtIODevice *vdev, + uint64_t requested_features, + unsigned int revision); uint64_t (*bad_features)(VirtIODevice *vdev); void (*set_features)(VirtIODevice *vdev, uint64_t val); int (*validate_features)(VirtIODevice *vdev); -- 1.7.9.5