[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PATCH v4 00/41] vfio: Adopt iommufd
|
From: |
Duan, Zhenzhong |
|
Subject: |
RE: [PATCH v4 00/41] vfio: Adopt iommufd |
|
Date: |
Wed, 8 Nov 2023 08:37:42 +0000 |
>-----Original Message-----
>From: Matthew Rosato <mjrosato@linux.ibm.com>
>Sent: Wednesday, November 8, 2023 11:27 AM
>Subject: Re: [PATCH v4 00/41] vfio: Adopt iommufd
>
>On 11/7/23 1:28 PM, Cédric Le Goater wrote:
>> On 11/2/23 08:12, Zhenzhong Duan wrote:
>>> Hi,
>>>
>>> Thanks all for giving guides and comments on previous series, here is
>>> the v4 of pure iommufd support part.
>>>
>>> Based on Cédric's suggestion, this series includes an effort to remove
>>> spapr code from container.c, now all spapr functions are moved to spapr.c
>>> or spapr_pci_vfio.c, but there are still a few trival check on
>>> VFIO_SPAPR_TCE_*_IOMMU which I am not sure if deserved to introduce
>many
>>> callbacks and duplicate code just to remove them. Some functions are moved
>>> to spapr.c instead of spapr_pci_vfio.c to avoid compile issue because
>>> spapr_pci_vfio.c is arch specific, or else we need to introduce stub
>>> functions to those spapr functions moved.
>>>
>>>
>>> PATCH 1-5: Move spapr functions to spapr*.c
>>> PATCH 6-20: Abstract out base container
>>> PATCH 21-24: Introduce sparpr container and its specific interface
>>
>> PATCH 6-24 applied to vfio-next :
>>
>> https://github.com/legoater/qemu/commits/vfio-next
>>
>> (with a global s/fucntional/functional/)
>>
>>
>> I also pushed the remaining patches on :
>>
>> https://github.com/legoater/qemu/commits/vfio-8.2
>>
>> with a slight rework of the IOMMUFD configuration, now done per platform.
>> The VFIO frontend and the 'iommufd' object are only available on x86_64,
>> arm, s390x.
Thanks Cédric.
>
>FYI, I first tried this vfio-8.2 branch on s390x but wasn't actually able to
>use the
>iommufd backend (was getting errors like Property 'vfio-pci.iommufd' not found)
>so I think something isn't actually enabling IOMMUFD as expected with your
>change...
It looks CONFIG_IOMMUFD is recognized by Kconfig sub-system but not received
by compiler. I'm still digging how to pass CONFIG_IOMMUFD to compiler.
>
>Instead I tested on s390x using vfio-next + patches 25-41 of this series on
>top.
>
>Legacy backend regression testing worked fine for vfio-pci, vfio-ap and
>vfio-ccw.
>
>Using iommufd backend for vfio-pci on s390 exposes an s390-only issue related
>to accounting of vfio DMA limit (code in hw/s390x/s390-pci-vfio.c assumes
>VFIODevice.group is never null, but that's no longer true when we use the
>iommufd backend with cdev). We don't even need to track this when using the
>iommufd backend -- With that issue bypassed, vfio-pci testing on s390x looks
>good so far. I'll send a separate fix for that.
Thanks for fixing that.
BRs.
Zhenzhong
>
>Using the iommufd backend for vfio-ccw and vfio-ap did not work, see response
>to patch 28.
>
>Thanks,
>Matt
- Re: [PATCH v4 38/41] vfio/ap: Make vfio cdev pre-openable by passing a file handle, (continued)
- [PATCH v4 39/41] vfio/ccw: Make vfio cdev pre-openable by passing a file handle, Zhenzhong Duan, 2023/11/02
- [PATCH v4 40/41] vfio: Make VFIOContainerBase poiner parameter const in VFIOIOMMUOps callbacks, Zhenzhong Duan, 2023/11/02
- [PATCH v4 41/41] vfio: Compile out iommufd for PPC target, Zhenzhong Duan, 2023/11/02
- Re: [PATCH v4 00/41] vfio: Adopt iommufd, Cédric Le Goater, 2023/11/06
- Re: [PATCH v4 00/41] vfio: Adopt iommufd, Cédric Le Goater, 2023/11/07
- Re: [PATCH v4 00/41] vfio: Adopt iommufd, Cédric Le Goater, 2023/11/08