On Thu, Jul 15, 2021 at 05:31:55PM +0100, Marc Zyngier wrote: > Add a pair of hooks (ioremap_page_range_hook/iounmap_page_range_hook) > that can be implemented by an architecture. > > Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx> > --- > include/linux/io.h | 3 +++ > mm/ioremap.c | 13 ++++++++++++- > mm/vmalloc.c | 8 ++++++++ > 3 files changed, 23 insertions(+), 1 deletion(-) > > diff --git a/include/linux/io.h b/include/linux/io.h > index 9595151d800d..0ffc265f114c 100644 > --- a/include/linux/io.h > +++ b/include/linux/io.h > @@ -21,6 +21,9 @@ void __ioread32_copy(void *to, const void __iomem *from, size_t count); > void __iowrite64_copy(void __iomem *to, const void *from, size_t count); > > #ifdef CONFIG_MMU > +void ioremap_page_range_hook(unsigned long addr, unsigned long end, > + phys_addr_t phys_addr, pgprot_t prot); > +void iounmap_page_range_hook(phys_addr_t phys_addr, size_t size); > int ioremap_page_range(unsigned long addr, unsigned long end, > phys_addr_t phys_addr, pgprot_t prot); > #else Can we avoid these hooks by instead not registering the regions proactively in the guest and moving that logic to a fault handler which runs off the back of the injected data abort? From there, we could check if the faulting IPA is a memory address and register it as MMIO if not. Dunno, you've spent more time than me thinking about this, but just wondering if you'd had a crack at doing it that way, as it _seems_ simpler to my naive brain. Will _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
