search for: ctrl_vq

...same DMA space to prevent > > > guests having the chance to bypass the host (e.g. QEMU) to > > > setup the backend accelerator directly. > > > > > > That's really good point.? So when "vhost" type is created, parent > > should assume addr of ctrl_vq is hva. > > > > Thanks > > > This works for vhost but not virtio since there's no way for virtio kernel > driver to differ ctrl_vq with the rest when doing DMA map. One possible > solution is to provide DMA domain isolation between virtqueues. Then ctrl vq > can...

...same DMA space to prevent > > > guests having the chance to bypass the host (e.g. QEMU) to > > > setup the backend accelerator directly. > > > > > > That's really good point.? So when "vhost" type is created, parent > > should assume addr of ctrl_vq is hva. > > > > Thanks > > > This works for vhost but not virtio since there's no way for virtio kernel > driver to differ ctrl_vq with the rest when doing DMA map. One possible > solution is to provide DMA domain isolation between virtqueues. Then ctrl vq > can...

...vent >>>>> guests having the chance to bypass the host (e.g. QEMU) to >>>>> setup the backend accelerator directly. >>>> >>>> That's really good point.? So when "vhost" type is created, parent >>>> should assume addr of ctrl_vq is hva. >>>> >>>> Thanks >>> >>> This works for vhost but not virtio since there's no way for virtio kernel >>> driver to differ ctrl_vq with the rest when doing DMA map. One possible >>> solution is to provide DMA domain isolation bet...

...vent >>>>> guests having the chance to bypass the host (e.g. QEMU) to >>>>> setup the backend accelerator directly. >>>> >>>> That's really good point.? So when "vhost" type is created, parent >>>> should assume addr of ctrl_vq is hva. >>>> >>>> Thanks >>> >>> This works for vhost but not virtio since there's no way for virtio kernel >>> driver to differ ctrl_vq with the rest when doing DMA map. One possible >>> solution is to provide DMA domain isolation bet...

...at 02:35:39PM +0800, Jason Wang wrote: >> This patch validates feature dependencies during probe and fail the probing >> if a dependency is missed. This fixes the issues of hitting BUG() >> when qemu fails to advertise features correctly. One example is booting >> guest with ctrl_vq=off through qemu. >> >> Cc: Rusty Russell <rusty at rustcorp.com.au> >> Cc: Michael S. Tsirkin <mst at redhat.com> >> Cc: Cornelia Huck <cornelia.huck at de.ibm.com> >> Cc: Wanlong Gao <gaowanlong at cn.fujitsu.com> >> Signed-off-by: Jason...

...at 02:35:39PM +0800, Jason Wang wrote: >> This patch validates feature dependencies during probe and fail the probing >> if a dependency is missed. This fixes the issues of hitting BUG() >> when qemu fails to advertise features correctly. One example is booting >> guest with ctrl_vq=off through qemu. >> >> Cc: Rusty Russell <rusty at rustcorp.com.au> >> Cc: Michael S. Tsirkin <mst at redhat.com> >> Cc: Cornelia Huck <cornelia.huck at de.ibm.com> >> Cc: Wanlong Gao <gaowanlong at cn.fujitsu.com> >> Signed-off-by: Jason...

On 2020/1/5 ??9:22, Michael S. Tsirkin wrote: > The only way for guest to control offloads (as enabled by > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands > through CTRL_VQ. So it does not make sense to > acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without > VIRTIO_NET_F_CTRL_VQ. > > The spec does not outlaw devices with such a configuration, so we have > to support it. Simply clear VIRTIO_NET_F_CTRL_GUEST_OFFLOADS. > Note that Linux is still crashi...

...S. Tsirkin wrote: > On Mon, Jan 06, 2020 at 10:47:35AM +0800, Jason Wang wrote: >> On 2020/1/5 ??9:22, Michael S. Tsirkin wrote: >>> The only way for guest to control offloads (as enabled by >>> VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands >>> through CTRL_VQ. So it does not make sense to >>> acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without >>> VIRTIO_NET_F_CTRL_VQ. >>> >>> The spec does not outlaw devices with such a configuration, so we have >>> to support it. Simply clear VIRTIO_NET_F_CTRL_GUEST_OFFLOA...

The only way for guest to control offloads (as enabled by VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands through CTRL_VQ. So it does not make sense to acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without VIRTIO_NET_F_CTRL_VQ. The spec does not outlaw devices with such a configuration, so we have to support it. Simply clear VIRTIO_NET_F_CTRL_GUEST_OFFLOADS. Note that Linux is still crashing if it tries to change the...

The only way for guest to control offloads (as enabled by VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands through CTRL_VQ. So it does not make sense to acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without VIRTIO_NET_F_CTRL_VQ. The spec does not outlaw devices with such a configuration, so we have to support it. Simply clear VIRTIO_NET_F_CTRL_GUEST_OFFLOADS. Note that Linux is still crashing if it tries to change the...

The only way for guest to control offloads (as enabled by VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands through CTRL_VQ. So it does not make sense to acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without VIRTIO_NET_F_CTRL_VQ. The spec does not outlaw devices with such a configuration, but Linux assumed that with VIRTIO_NET_F_CTRL_GUEST_OFFLOADS control vq is always there, resulting in the following crash when config...

...>>>>> it? Just set ctrl vq >>>>>>> address and let parent to deal with that. >>>>>> I mean how to expose ctrlq related settings to userspace? >>>>> I think it works like: >>>>> >>>>> 1) userspace find ctrl_vq is supported >>>>> >>>>> 2) then it can allocate memory for ctrl vq and set its address through >>>>> vhost-mdev >>>>> >>>>> 3) userspace can populate ctrl vq itself >>>> I see. That is to say, userspace e.g. QEM...

...>>>>> it? Just set ctrl vq >>>>>>> address and let parent to deal with that. >>>>>> I mean how to expose ctrlq related settings to userspace? >>>>> I think it works like: >>>>> >>>>> 1) userspace find ctrl_vq is supported >>>>> >>>>> 2) then it can allocate memory for ctrl vq and set its address through >>>>> vhost-mdev >>>>> >>>>> 3) userspace can populate ctrl vq itself >>>> I see. That is to say, userspace e.g. QEM...

...s return error here? > @@ -2971,6 +2974,15 @@ static int virtnet_validate(struct virtio_device *vdev) > if (!virtnet_validate_features(vdev)) > return -EINVAL; > > + /* VIRTIO_NET_F_CTRL_GUEST_OFFLOADS does not work without > + * VIRTIO_NET_F_CTRL_VQ. However the virtio spec does not > + * specify that VIRTIO_NET_F_CTRL_GUEST_OFFLOADS depends > + * on VIRTIO_NET_F_CTRL_VQ so devices can set the later but > + * not the former. > + */ > + if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ)) > +...

...return -EBUSY; > @@ -2971,6 +2974,15 @@ static int virtnet_validate(struct virtio_device *vdev) > if (!virtnet_validate_features(vdev)) > return -EINVAL; > > + /* VIRTIO_NET_F_CTRL_GUEST_OFFLOADS does not work without > + * VIRTIO_NET_F_CTRL_VQ. However the virtio spec does not > + * specify that VIRTIO_NET_F_CTRL_GUEST_OFFLOADS depends > + * on VIRTIO_NET_F_CTRL_VQ so devices can set the later but > + * not the former. > + */ > + if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ)) > +...

...t; > + /* Return status and session id back */ >>> > > + sg_init_one(&inhdr, &vcrypto->input, sizeof(vcrypto->input)); >>> > > + sgs[num_out + num_in++] = &inhdr; >>> > > + >>> > > + err = virtqueue_add_sgs(vcrypto->ctrl_vq, sgs, num_out, >>> > > + num_in, vcrypto, GFP_ATOMIC); >>> > > + if (err < 0) { >>> > > + spin_unlock(&vcrypto->ctrl_lock); >>> > > + kfree(cipher_key); >>> > > + return err; >>> > > + } >&g...

...t; > + /* Return status and session id back */ >>> > > + sg_init_one(&inhdr, &vcrypto->input, sizeof(vcrypto->input)); >>> > > + sgs[num_out + num_in++] = &inhdr; >>> > > + >>> > > + err = virtqueue_add_sgs(vcrypto->ctrl_vq, sgs, num_out, >>> > > + num_in, vcrypto, GFP_ATOMIC); >>> > > + if (err < 0) { >>> > > + spin_unlock(&vcrypto->ctrl_lock); >>> > > + kfree(cipher_key); >>> > > + return err; >>> > > + } >&g...

On Thu, 13 Nov 2014 13:52:54 +0800 Jason Wang <jasowang at redhat.com> wrote: > This patch tries to detect the possible buggy features advertised by host > and fix them. One example is booting virtio-net with only ctrl_vq disabled, > qemu may still advertise many features which depends on it. This will > trigger several BUG()s in virtnet_send_command(). > > This patch utilizes the fix_features() method, and disables all features that > depends on ctrl_vq if it was not advertised. > > This fixe...

On Thu, 13 Nov 2014 13:52:54 +0800 Jason Wang <jasowang at redhat.com> wrote: > This patch tries to detect the possible buggy features advertised by host > and fix them. One example is booting virtio-net with only ctrl_vq disabled, > qemu may still advertise many features which depends on it. This will > trigger several BUG()s in virtnet_send_command(). > > This patch utilizes the fix_features() method, and disables all features that > depends on ctrl_vq if it was not advertised. > > This fixe...

On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote: > Add a new vq, ctrl_vq, to handle commands between the host and guest. > With this feature, we will be able to have the control plane and data > plane separated. In other words, the control related commands of each > feature will be sent via the ctrl_vq, meanwhile each feature may have > its own vq used as a...