>-----Original Message-----
>From: Eric Auger <eric.auger@redhat.com>
>Sent: Monday, November 20, 2023 5:15 PM
>Subject: Re: [PATCH v6 00/21] vfio: Adopt iommufd
>
>Hi Zhenzhong,
>
>On 11/14/23 11:09, Zhenzhong Duan wrote:
>> Hi,
>>
>> Thanks all for giving guides and comments on previous series, this is
>> the remaining part of the iommufd support.
>>
>> Based on Cédric's suggestion, replace old config method for IOMMUFD
>> with Kconfig.
>>
>> Based on Jason's suggestion, drop the implementation of manually
>> allocating hwpt and switch to IOAS attach/detach.
>>
>> Beside current test, we also tested mdev with mtty for better cover range.
>>
>> PATCH 1: Introduce iommufd object
>> PATCH 2-9: add IOMMUFD container and cdev support
>> PATCH 10-17: fd passing for cdev and linking to IOMMUFD
>> PATCH 18: make VFIOContainerBase parameter const
>> PATCH 19-21: Compile out for IOMMUFD for arm, s390x and x86
>>
>>
>> We have done wide test with different combinations, e.g:
>> - PCI device were tested
>> - FD passing and hot reset with some trick.
>> - device hotplug test with legacy and iommufd backends
>> - with or without vIOMMU for legacy and iommufd backends
>> - divices linked to different iommufds
>> - VFIO migration with a E800 net card(no dirty sync support) passthrough
>> - platform, ccw and ap were only compile-tested due to environment limit
>> - test mdev pass through with mtty and mix with real device and different BE
>>
>> Given some iommufd kernel limitations, the iommufd backend is
>> not yet fully on par with the legacy backend w.r.t. features like:
>> - p2p mappings (you will see related error traces)
>> - dirty page sync
>> - and etc.
>
>Feel free to add my T-b:
>Tested-by: Eric Auger <eric.auger@redhat.com>

Thanks Eric, you mean all the patches or arm part?

BRs.
Zhenzhong

Hi Zhengzhong

On 11/20/23 11:09, Duan, Zhenzhong wrote:
>
>> -----Original Message-----
>> From: Eric Auger <eric.auger@redhat.com>
>> Sent: Monday, November 20, 2023 5:15 PM
>> Subject: Re: [PATCH v6 00/21] vfio: Adopt iommufd
>>
>> Hi Zhenzhong,
>>
>> On 11/14/23 11:09, Zhenzhong Duan wrote:
>>> Hi,
>>>
>>> Thanks all for giving guides and comments on previous series, this is
>>> the remaining part of the iommufd support.
>>>
>>> Based on Cédric's suggestion, replace old config method for IOMMUFD
>>> with Kconfig.
>>>
>>> Based on Jason's suggestion, drop the implementation of manually
>>> allocating hwpt and switch to IOAS attach/detach.
>>>
>>> Beside current test, we also tested mdev with mtty for better cover range.
>>>
>>> PATCH 1: Introduce iommufd object
>>> PATCH 2-9: add IOMMUFD container and cdev support
>>> PATCH 10-17: fd passing for cdev and linking to IOMMUFD
>>> PATCH 18: make VFIOContainerBase parameter const
>>> PATCH 19-21: Compile out for IOMMUFD for arm, s390x and x86
>>>
>>>
>>> We have done wide test with different combinations, e.g:
>>> - PCI device were tested
>>> - FD passing and hot reset with some trick.
>>> - device hotplug test with legacy and iommufd backends
>>> - with or without vIOMMU for legacy and iommufd backends
>>> - divices linked to different iommufds
>>> - VFIO migration with a E800 net card(no dirty sync support) passthrough
>>> - platform, ccw and ap were only compile-tested due to environment limit
>>> - test mdev pass through with mtty and mix with real device and different BE
>>>
>>> Given some iommufd kernel limitations, the iommufd backend is
>>> not yet fully on par with the legacy backend w.r.t. features like:
>>> - p2p mappings (you will see related error traces)
>>> - dirty page sync
>>> - and etc.
>> Feel free to add my T-b:
>> Tested-by: Eric Auger <eric.auger@redhat.com>
> Thanks Eric, you mean all the patches or arm part?

Yeah sorry I failed to give details. I have tested on ARM with vfio-pci
atm. So all the generic patches + ARM virt / PCI specific ones. As for
VFIO-PLATFORM I need to resurrect a new environment because I have some
trouble with AMD overdrive which do not expose iommu groups atm. I need
to figure this out or create a new vfio-platform environment to test.
Working on it ...

Thanks

Eric
>
> BRs.
> Zhenzhong