Re: [PATCH v3 00/19] IOMMUFD Dirty Tracking

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

 



On 13/10/2023 17:29, Jason Gunthorpe wrote:
> On Sat, Sep 23, 2023 at 02:24:52AM +0100, Joao Martins wrote:
> 
>> Joao Martins (19):
>>   vfio/iova_bitmap: Export more API symbols
>>   vfio: Move iova_bitmap into iommu core
>>   iommu: Add iommu_domain ops for dirty tracking
>>   iommufd: Add a flag to enforce dirty tracking on attach
>>   iommufd/selftest: Expand mock_domain with dev_flags
>>   iommufd/selftest: Test IOMMU_HWPT_ALLOC_ENFORCE_DIRTY
>>   iommufd: Dirty tracking data support
>>   iommufd: Add IOMMU_HWPT_SET_DIRTY
>>   iommufd/selftest: Test IOMMU_HWPT_SET_DIRTY
>>   iommufd: Add IOMMU_HWPT_GET_DIRTY_IOVA
>>   iommufd/selftest: Test IOMMU_HWPT_GET_DIRTY_IOVA
>>   iommufd: Add capabilities to IOMMU_GET_HW_INFO
>>   iommufd/selftest: Test out_capabilities in IOMMU_GET_HW_INFO
>>   iommufd: Add a flag to skip clearing of IOPTE dirty
>>   iommufd/selftest: Test IOMMU_GET_DIRTY_IOVA_NO_CLEAR flag
>>   iommu/amd: Add domain_alloc_user based domain allocation
>>   iommu/amd: Access/Dirty bit support in IOPTEs
>>   iommu/amd: Print access/dirty bits if supported
>>   iommu/intel: Access/Dirty bit support for SL domains
> 
> I read through this and I'm happy with the design - small points aside
> 
Great!

> Suggest to fix those and resend ASAP.
> 
> Kevin, you should check it too
> 
> If either AMD or Intel ack the driver part next week I would take it
> this cycle. Otherwise at -rc1.
> 
FWIW, I feel more confident on the AMD parts as they have been exercised on real
hardware.

Suravee, Vasant, if you could take a look at the AMD driver patches -- you
looked at a past revision (RFCv1) and provided comments but while I took the
comments I didn't get Suravee's ACK as things were in flux on the UAPI side. But
it looks that v4 won't change much of the drivers

> Also I recommend you push all the selftest to a block of patches at
> the end of the series so the core code reads as one chunk. It doesn't
> seem as large that way :)
> 
Ah OK, interesting -- good to know, I can move to the end. I thought the desired
way (for reviewing purpose) was to put test right after, such that the reviewer
has it fresh while looking at the test code



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux