On Mon, Feb 21, 2022 at 04:15:22PM +0000, David Woodhouse wrote:
As things stand, an application which wants to use vhost with a trivial 1:1 mapping of its virtual address space is forced to jump through hoops to detect what the address range might be. The VHOST_SET_MEM_TABLE ioctl helpfully doesn't fail immediately; you only get a failure *later* when you attempt to set the backend, if the table *could* map to an address which is out of range, even if no out-of-range address is actually being referenced. Since userspace is growing workarounds for this lovely kernel API, let's ensure that we have a regression test that does things basically the same way as https://gitlab.com/openconnect/openconnect/-/commit/443edd9d8826 does. This is untested as I can't actually get virtio_test to work at all; it just seems to deadlock on a spinlock. But it's getting the right answer for the virtio range on x86_64 at least.
I had a similar issue with virtio_test and this simple patch [1] should fix the deadlock.
[1] https://lore.kernel.org/lkml/20220118150631.167015-1-sgarzare@xxxxxxxxxx/
Stefano _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
