On 11/8/22 9:04 AM, Anthony Krowiak wrote:
On 11/8/22 5:12 AM, Christian Borntraeger wrote:
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.
I'm looking into it.
I cloned the
https://lore.kernel.org/kvm/Y2q3nFXwOk9jul5u@xxxxxxxxxx/T/#m76a9c609c5ccd1494c05c6f598f9c8e75b7c9888
repo and ran the vfio_ap test cases. The tests ran without encountering
the errors related to the vfio_pin_pages() function, but I did see two
tests fail attempting to run crypto tests on the guest. I also saw a
WARN_ON stack trace in the dmesg output indicating a timeout occurred
trying to verify the completion of a queue reset. The reset problem has
reared its ugly head in our CI, so this may be a good thing as it will
allow me to debug why its happening.
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
