search for: check_legacy

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

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

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

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

...rote: > 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? Yes. > > > > > For ccw, this would check for the negotiated revision; for mmi...

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

...rote: > 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? Yes. > > > > > For ccw, this would check for the negotiated revision; for mmi...

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

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

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

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

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