search for: is_legacy

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

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

...queue. */ @@ -303,10 +319,66 @@ static int virtio_ccw_set_vqs(SubchDev *sch, uint64_t addr, uint32_t align, return 0; } -static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw) +static int virtio_ccw_handle_set_vq(SubchDev *sch, CCW1 ccw, bool check_len, + bool is_legacy) { int ret; VqInfoBlock info; + VqInfoBlockLegacy linfo; + size_t info_len = is_legacy ? sizeof(linfo) : sizeof(info); + + if (check_len) { + if (ccw.count != info_len) { + return -EINVAL; + } + } else if (ccw.count < info_len) { + /* Can...

...queue. */ @@ -303,10 +319,66 @@ static int virtio_ccw_set_vqs(SubchDev *sch, uint64_t addr, uint32_t align, return 0; } -static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw) +static int virtio_ccw_handle_set_vq(SubchDev *sch, CCW1 ccw, bool check_len, + bool is_legacy) { int ret; VqInfoBlock info; + VqInfoBlockLegacy linfo; + size_t info_len = is_legacy ? sizeof(linfo) : sizeof(info); + + if (check_len) { + if (ccw.count != info_len) { + return -EINVAL; + } + } else if (ccw.count < info_len) { + /* Can...

...> > 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? I would say have modern_features, legacy_features, and set host_features correctly. -- MST

...> > 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? Also, let's focus on one device, e.g. -net for now. Then probably virtio scsi. That's because blk needs to be reworked to support ANY_LAYOUT. -- MST

On Tue, 2015-01-20 at 17:44 +0000, Michael S. Tsirkin wrote: > Good. But your current code will also try to support a mix: device that > uses the new transport underneath, but old layout and semantics on top. It will not try to support the mix, but rather will not stop it from working. > This has no value: the spec does *not* define such devices > and it also does not match any

...> > 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? I would say have modern_features, legacy_features, and set host_features correctly. -- MST

...> > 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? Also, let's focus on one device, e.g. -net for now. Then probably virtio scsi. That's because blk needs to be reworked to support ANY_LAYOUT. -- MST

On Tue, 2015-01-20 at 17:44 +0000, Michael S. Tsirkin wrote: > Good. But your current code will also try to support a mix: device that > uses the new transport underneath, but old layout and semantics on top. It will not try to support the mix, but rather will not stop it from working. > This has no value: the spec does *not* define such devices > and it also does not match any

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

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

Hi, here's the next version of my virtio-1 qemu patchset. Using virtio-1 virtio-blk and virtio-net devices with a guest kernel built from <1416829787-14252-1-git-send-email-mst at redhat.com> still seems to work for the virtio-ccw transport. Changes from v1: - rebased against current master - don't advertise VERSION_1 for all devices, make devices switch it on individually

Hi, here's the next version of my virtio-1 qemu patchset. Using virtio-1 virtio-blk and virtio-net devices with a guest kernel built from <1416829787-14252-1-git-send-email-mst at redhat.com> still seems to work for the virtio-ccw transport. Changes from v1: - rebased against current master - don't advertise VERSION_1 for all devices, make devices switch it on individually

Next version of virtio-1 patches for qemu. Only change from v2 is splitting out the vring accessors into a separate header file - should hopefully fix the build issues. Cornelia Huck (9): 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 virtio: allow virtio-1 queue layout

Next version of virtio-1 patches for qemu. Only change from v2 is splitting out the vring accessors into a separate header file - should hopefully fix the build issues. Cornelia Huck (9): 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 virtio: allow virtio-1 queue layout

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

This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands Thanks go to Thomas for some preliminary work in this area. I've been able to start guests both with and without the

This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands Thanks go to Thomas for some preliminary work in this area. I've been able to start guests both with and without the