Hi Mike,
On Wed, Apr 28, 2021 at 05:36:59PM -0500, Mike Christie wrote:
The following patches apply over mst's vhost branch and were tested
againt that branch and also mkp's 5.13 branch which has some vhost-scsi
changes.
These patches allow us to support multiple vhost workers per device. I
ended up just doing Stefan's original idea where userspace has the
kernel create a worker and we pass back the pid. This has the benefit
over the workqueue and userspace thread approach where we only have
one'ish code path in the kernel.
The kernel patches here allow us to then do N workers device and also
share workers across devices.
I took a first look and left a few comments.
In general it looks good to me, I'm just worried if it's okay to use the
kthread pid directly or it's better to use an internal id.
For example I think if this can be affected by the pid namespaces or
some security issues.
I admit I don't know much about this topic, so this might be silly.
I included a patch for qemu so you can get an idea of how it works.
TODO:
-----
- polling
- Allow sharing workers across devices. Kernel support is added and I
hacked up userspace to test, but I'm still working on a sane way to
manage it in userspace.
- Bind to specific CPUs. Commands like "virsh emulatorpin" work with
these patches and allow us to set the group of vhost threads to different
CPUs. But we can also set a specific vq's worker to run on a CPU.
- I'm handling old kernel by just checking for EPERM. Does this require
a feature?
Do you mean when the new ioctls are not available? We do not return
ENOIOCTLCMD?
In this case I think is fine to check the return value.
Thanks,
Stefano
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
