Am 08.11.22 um 02:09 schrieb Jason Gunthorpe:
On Mon, Nov 07, 2022 at 08:48:53PM -0400, Jason Gunthorpe wrote:
[
This has been in linux-next for a little while now, and we've completed
the syzkaller run. 1300 hours of CPU time have been invested since the
last report with no improvement in coverage or new detections. syzkaller
coverage reached 69%(75%), and review of the misses show substantial
amounts are WARN_ON's and other debugging which are not expected to be
covered.
]
iommufd is the user API to control the IOMMU subsystem as it relates to
managing IO page tables that point at user space memory.
[chop cc list]
s390 mdev maintainers,
Can I ask your help to test this with the two S390 mdev drivers? Now
that gvt is passing and we've covered alot of the QA ground it is a
good time to run it.
Take the branch from here:
https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/log/?h=for-next
And build the kernel with
CONFIG_VFIO_CONTAINER=n
CONFIG_IOMMUFD=y
CONFIG_IOMMUFD_VFIO_CONTAINER=y
And your existing stuff should work with iommufd providing the iommu
support to vfio. There will be a dmesg confirming this.
Gave it a quick spin with vfio_ap:
[ 401.679199] vfio_ap_mdev b01a7c33-9696-48b2-9a98-050e8e17c69a: Adding to iommu group 1
[ 402.085386] iommufd: IOMMUFD is providing /dev/vfio/vfio, not VFIO.
Some tests seem to work, but others dont (running into timeouts). I need to look
into that (or ideally Tony will have a look, FWIW tests.test_vfio_ap.VfioAPAssignMdevToGuestTest
fails for me.
The same kernel tree with defconfig (instead of CONFIG_IOMMUFD_VFIO_CONTAINER=y) works fine.
Let me know if there are any problems!
If I recall there was some desire from the S390 platform team to start
building on iommufd to create some vIOMMU acceleration for S390
guests, this is a necessary first step.
Thanks,
Jason
