Re: S390 testing for IOMMUFD

[Anthony Krowiak <akrowiak@linux.ibm.com>]

On 11/9/22 9:49 AM, Anthony Krowiak wrote:
>
> 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@nvidia.com/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 problems I encountered were due to using a set of regression tests 
that were not vanilla. They contained some changes I made to try to 
improve performance of the tests. After restoring the vanilla regression 
tests, I was able to successfully execute the tests without any problems 
or errors with Jason's vfio_ap_(un)pin_pages patch installed, so that 
looks good to 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