search for: legacy_features

...v 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, > > w...

...v 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, > > w...

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

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

...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? Yes. > > > > > For ccw, this would check for the negotiated revision; for mmio, it > > > could check a device property configured with...

...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? Yes. > > > > > For ccw, this would check for the negotiated revision; for mmio, it > > > could check a device property configured with...

...o 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? The basic problem is that we decide via a feature bit that needs to be negotiated which feature bits we want to present. pci and mmio don...

...o 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? The basic problem is that we decide via a feature bit that needs to be negotiated which feature bits we want to present. pci and mmio don...

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

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

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

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

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

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

...; 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. > Cornelia Huck (13): > virtio: cull virtio_bus_set_vdev_features > virtio: support more feature bits > s390x/virtio-ccw: fix check for WRITE_FEAT > virtio: introduce legacy virtio devices > v...

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

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