Re: [RFC PATCH v3 02/10] iommupt: Add RISC-V dirty tracking PTE ops
| Newsgroups | dev.linux.lists.iommu,org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
>> From: Fangyu Yu <[email protected]> >> >> Implement the three dirty-tracking hooks required by the generic page >> table framework for the RISC-V format: >> >> pt_entry_is_write_dirty(): >> Check the D bit (bit 7) in the PTE. >> >> pt_entry_make_write_clean(): >> Clear the D bit across the full contiguous range. >> >> pt_entry_make_write_dirty(): >> Atomically set D via try_cmpxchg64() on a single PTE. >> >> Signed-off-by: Fangyu Yu <[email protected]> >> --- >> drivers/iommu/generic_pt/fmt/riscv.h | 43 ++++++++++++++++++++++++++++ >> 1 file changed, 43 insertions(+) >> >> diff --git a/drivers/iommu/generic_pt/fmt/riscv.h b/drivers/iommu/generic_pt/fmt/riscv.h >> index 5692c033dbde..09581798e753 100644 >> --- a/drivers/iommu/generic_pt/fmt/riscv.h >> +++ b/drivers/iommu/generic_pt/fmt/riscv.h >> @@ -226,6 +226,49 @@ static inline void riscvpt_attr_from_entry(const struct pt_state *pts, >> } >> #define pt_attr_from_entry riscvpt_attr_from_entry > >Does this work for all stages or does it need pt_dirty_supported ? Good catch, no it doesn't. This patch didn't add a pt_dirty_supported(), so it falls back to the default "always true", which isn't right -- iommu.c only sets TC.GADE and wires up dirty_ops for second-stage domains, first-stage never gets TC.SADE set. Thanks, Fangyu > >Jason >