Re: S390 testing for IOMMUFD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux