On Tue, Oct 26, 2021 at 11:45 PM Stefan Hajnoczi <stefanha@xxxxxxxxxx> wrote: > > On Tue, Oct 26, 2021 at 01:37:14PM +0800, Jason Wang wrote: > > > > 在 2021/10/22 下午1:19, Mike Christie 写道: > > > This patch allows userspace to create workers and bind them to vqs. You > > > can have N workers per dev and also share N workers with M vqs. > > > > > > Signed-off-by: Mike Christie <michael.christie@xxxxxxxxxx> > > > > > > A question, who is the best one to determine the binding? Is it the VMM > > (Qemu etc) or the management stack? If the latter, it looks to me it's > > better to expose this via sysfs? > > A few options that let the management stack control vhost worker CPU > affinity: > > 1. The management tool opens the vhost device node, calls > ioctl(VHOST_SET_VRING_WORKER), sets up CPU affinity, and then passes > the fd to the VMM. In this case the VMM is still able to call the > ioctl, which may be undesirable from an attack surface perspective. Yes, and we can't do post or dynamic configuration afterwards after the VM is launched? > > 2. The VMM calls ioctl(VHOST_SET_VRING_WORKER) itself and the management > tool queries the vq:worker details from the VMM (e.g. a new QEMU QMP > query-vhost-workers command similar to query-iothreads). The > management tool can then control CPU affinity on the vhost worker > threads. > > (This is how CPU affinity works in QEMU and libvirt today.) Then we also need a "bind-vhost-workers" command. > > 3. The sysfs approach you suggested. Does sysfs export vq-0/, vq-1/, etc > directories with a "worker" attribute? Something like this. > Do we need to define a point > when the VMM has set up vqs and the management stack is able to query > them? It could be the point that the vhost fd is opened. > Vhost devices currently pre-allocate the maximum number of vqs > and I'm not sure how to determine the number of vqs that will > actually be used? It requires more information to be exposed. But before this, we should allow the dynamic binding of between vq and worker. > > One advantage of this is that access to the vq:worker mapping can be > limited to the management stack and the VMM cannot access it. But it > seems a little tricky because the vhost model today doesn't use sysfs > or define a lifecycle where the management stack can configure > devices. Yes. Thanks > > Stefan
