On Fri, Oct 25, 2019 at 05:54:55PM +0800, Jason Wang wrote:
>
> On 2019/10/24 下午6:42, Jason Wang wrote:
> >
> > Yes.
> >
> >
> > > And we should try to avoid
> > > putting ctrl vq and Rx/Tx vqs in the 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 use its dedicated DMA domain for the work.
>
> Anyway, this could be done in the future. We can have a version first that
> doesn't support ctrl_vq.
>
> Thanks
Well no ctrl_vq implies either no offloads, or no XDP (since XDP needs
to disable offloads dynamically).
if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS)
&& (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO4) ||
virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO6) ||
virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_ECN) ||
virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_UFO) ||
virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))) {
NL_SET_ERR_MSG_MOD(extack, "Can't set XDP while host is implementing LRO/CSUM, disable LRO/CSUM first");
return -EOPNOTSUPP;
}
neither is very attractive.
So yes ok just for development but we do need to figure out how it will
work down the road in production.
So really this specific virtio net device does not support control vq,
instead it supports a different transport specific way to send commands
to device.
Some kind of extension to the transport? Ideas?
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
