Re: [RFC] Use SMMU HTTU for DMA dirty page tracking

Hi Jean and Kevin,

FYI, I have send out the SMMUv3 HTTU support for DMA dirty tracking[1] a week ago.

Thanks,
Keqian

[1] https://lore.kernel.org/linux-iommu/20210128151742.18840-1-zhukeqian1@huawei.com/ (local)

On 2020/5/27 17:14, Jean-Philippe Brucker wrote:

On Wed, May 27, 2020 at 08:40:47AM +0000, Tian, Kevin wrote:

quoted

quoted

From: Xiang Zheng <redacted>
Sent: Wednesday, May 27, 2020 2:45 PM


On 2020/5/27 11:27, Tian, Kevin wrote:

quoted

quoted

From: Xiang Zheng
Sent: Monday, May 25, 2020 7:34 PM

[+cc Kirti, Yan, Alex]

On 2020/5/23 1:14, Jean-Philippe Brucker wrote:

quoted

Hi,

On Tue, May 19, 2020 at 05:42:55PM +0800, Xiang Zheng wrote:

quoted

Hi all,

Is there any plan for enabling SMMU HTTU?

Not outside of SVA, as far as I know.

quoted

quoted

I have seen the patch locates in the SVA series patch, which adds
support for HTTU:
    https://www.spinics.net/lists/arm-kernel/msg798694.html

HTTU reduces the number of access faults on SMMU fault queue
(permission faults also benifit from it).

Besides reducing the faults, HTTU also helps to track dirty pages for
device DMA. Is it feasible to utilize HTTU to get dirty pages on device
DMA during VFIO live migration?

As you know there is a VFIO interface for this under discussion:
https://lore.kernel.org/kvm/1589781397-28368-1-git-send-email-

kwankhede@nvidia.com/

quoted

It doesn't implement an internal API to communicate with the IOMMU

driver

quoted

about dirty pages.

We plan to add such API later, e.g. to utilize A/D bit in VT-d 2nd-level
page tables (Rev 3.0).

Thank you, Kevin.

When will you send this series patches? Maybe(Hope) we can also support
hardware-based dirty pages tracking via common APIs based on your
patches. :)

Yan is working with Kirti on basic live migration support now. After that
part is done, we will start working on A/D bit support. Yes, common APIs
are definitely the goal here.

quoted

quoted

quoted

quoted

quoted

If SMMU can track dirty pages, devices are not required to implement
additional dirty pages tracking to support VFIO live migration.

It seems feasible, though tracking it in the device might be more
efficient. I might have misunderstood but I think for live migration of
the Intel NIC they trap guest accesses to the device and introspect its
state to figure out which pages it is accessing.

Does HTTU implement A/D-like mechanism in SMMU page tables, or just
report dirty pages in a log buffer? Either way tracking dirty pages in IOMMU
side is generic thus doesn't require device-specific tweak like in Intel NIC.

Currently HTTU just implement A/D-like mechanism in SMMU page tables.
We certainly
expect SMMU can also implement PML-like feature so that we can avoid
walking the
whole page table to get the dirty pages.

There is no reporting of dirty pages in log buffer. It might be possible
to do software logging based on PRI or Stall, but that requires special
support in the endpoint as well as the SMMU.

quoted

Is there a link to HTTU introduction?

I don't know any gentle introduction, but there are sections D5.4.11
"Hardware management of the Access flag and dirty state" in the ARM
Architecture Reference Manual (DDI0487E), and section 3.13 "Translation
table entries and Access/Dirty flags" in the SMMU specification
(IHI0070C). HTTU stands for "Hardware Translation Table Update".

In short, when HTTU is enabled, the SMMU translation performs an atomic
read-modify-write on the leaf translation table descriptor, setting some
bits depending on the type of memory access. This can be enabled
independently on both stage-1 and stage-2 tables (equivalent to your 1st
and 2nd page tables levels, I think).

Thanks,
Jean
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel