[PATCH] x86/paravirt: Add ioremap_verify_range hook and implement it for Xen PV

[PATCH] x86/paravirt: Add ioremap_verify_range hook and implement it for Xen PV

[Jason Andryuk]

Xen PV guests update page tables via hypercalls, and Xen refuses to let a
domain map machine frames it does not own, such as chipset MMIO in a domU.
The set_pte() paths ignore the hypercall result, so ioremap() returns a
mapping whose PTEs are not present.  Accessing the virtual address then
faults.  This was seen in print_s5_reset_status_mmio() on Xen PV domUs
on AMD Zen hosts.  The machine address is not accessible by the domU and
faults on access.

Add a pv_mmu_ops hook, ioremap_verify_range, which __ioremap_caller()
calls after ioremap_page_range().  It defaults to returning success.
Xen PV implements it by walking the range with lookup_address() and
failing if any entry is not present, making ioremap() return NULL.

This also affects a Xen PV dom0: an ioremap() of a range containing any
page Xen refuses to map (e.g. MMIO Xen reserves for itself) now fails as
a whole, rather than succeeding and faulting only when the refused page
is accessed.  Pages Xen forces read-only are still mapped present and
are unaffected.

Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset")
Link: https://lore.kernel.org/xen-devel/20251219010131.12659-1-ariadne@ariadne.space/
Suggested-by: Sean Christopherson <seanjc@google.com>
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
---
 arch/x86/include/asm/paravirt.h       | 10 ++++++++++
 arch/x86/include/asm/paravirt_types.h |  6 ++++++
 arch/x86/kernel/paravirt.c            |  7 +++++++
 arch/x86/mm/ioremap.c                 |  3 +++
 arch/x86/xen/mmu_pv.c                 | 24 ++++++++++++++++++++++++
 5 files changed, 50 insertions(+)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 0591aa38fd85..30cb1d1636e4 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -495,6 +495,11 @@ static inline void arch_leave_lazy_mmu_mode(void)
 	arch_flush_lazy_mmu_mode();
 }
 
+static inline int ioremap_verify_range(unsigned long addr, unsigned long size)
+{
+	return PVOP_CALL2(int, pv_ops, mmu.ioremap_verify_range, addr, size);
+}
+
 static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
 				phys_addr_t phys, pgprot_t flags)
 {
@@ -557,6 +562,11 @@ static __always_inline unsigned long arch_local_irq_save(void)
 static inline void paravirt_enter_mmap(struct mm_struct *mm)
 {
 }
+
+static inline int ioremap_verify_range(unsigned long addr, unsigned long size)
+{
+	return 0;
+}
 #endif
 
 #ifndef CONFIG_PARAVIRT
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index b4c4a23e77a1..674613301a83 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -164,6 +164,12 @@ struct pv_mmu_ops {
 
 	void (*lazy_mode_flush)(void);
 
+	/*
+	 * Verify that an ioremap()ed kernel virtual address range was
+	 * actually mapped.  Returns 0 on success.
+	 */
+	int (*ioremap_verify_range)(unsigned long addr, unsigned long size);
+
 	/* dom0 ops */
 
 	/* Sometimes the physical address is a pfn, and sometimes its
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 00b59d774389..b1bc519c660d 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -88,6 +88,11 @@ static noinstr void pv_native_set_debugreg(int regno, unsigned long val)
 {
 	native_set_debugreg(regno, val);
 }
+
+static int native_ioremap_verify_range(unsigned long addr, unsigned long size)
+{
+	return 0;
+}
 #endif
 
 struct pv_info pv_info = {
@@ -207,6 +212,8 @@ struct paravirt_patch_template pv_ops = {
 
 	.mmu.lazy_mode_flush	= paravirt_nop,
 
+	.mmu.ioremap_verify_range	= native_ioremap_verify_range,
+
 	.mmu.set_fixmap		= native_set_fixmap,
 #endif /* CONFIG_PARAVIRT_XXL */
 };
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 12c8180ca1ba..6b45a7eef593 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -301,6 +301,9 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
 	if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot))
 		goto err_free_area;
 
+	if (ioremap_verify_range(vaddr, size))
+		goto err_free_area;
+
 	ret_addr = (void __iomem *) (vaddr + offset);
 	mmiotrace_ioremap(unaligned_phys_addr, unaligned_size, ret_addr);
 
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 377c3c0d9f20..e524d318171f 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -359,6 +359,29 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+/*
+ * PTE updates are made via (possibly batched) hypercalls whose failures
+ * are not propagated back to the caller.  Xen refuses to let a domain map
+ * machine frames it does not own (e.g. chipset MMIO in a domU), leaving the
+ * PTE not present.  Walk the range to make sure every page got mapped.
+ */
+static int xen_ioremap_verify_range(unsigned long addr, unsigned long size)
+{
+	unsigned long end = addr + size;
+	unsigned int level;
+	pte_t *pte;
+
+	while (addr < end) {
+		pte = lookup_address(addr, &level);
+		if (!pte || !pte_present(*pte))
+			return -ENXIO;
+
+		addr = (addr & page_level_mask(level)) + page_level_size(level);
+	}
+
+	return 0;
+}
+
 static pte_t xen_ptep_modify_prot_start(struct vm_area_struct *vma,
 					unsigned long addr, pte_t *ptep)
 {
@@ -2218,6 +2241,7 @@ void __init xen_init_mmu_ops(void)
 	pv_ops.mmu.enter_mmap = xen_enter_mmap;
 	pv_ops.mmu.exit_mmap = xen_exit_mmap;
 	pv_ops.mmu.lazy_mode_flush = xen_flush_lazy_mmu;
+	pv_ops.mmu.ioremap_verify_range = xen_ioremap_verify_range;
 	pv_ops.mmu.set_fixmap = xen_set_fixmap;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
-- 
2.34.1

Re: [PATCH] x86/paravirt: Add ioremap_verify_range hook and implement it for Xen PV

[Borislav Petkov]

On Fri, Oct 30, 2026 at 08:33:08PM -0400, Jason Andryuk wrote:
> Xen PV guests update page tables via hypercalls, and Xen refuses to let a
> domain map machine frames it does not own, such as chipset MMIO in a domU.
> The set_pte() paths ignore the hypercall result, so ioremap() returns a
> mapping whose PTEs are not present.  Accessing the virtual address then
> faults.  This was seen in print_s5_reset_status_mmio() on Xen PV domUs
> on AMD Zen hosts.  The machine address is not accessible by the domU and
> faults on access.
> 
> Add a pv_mmu_ops hook, ioremap_verify_range, which __ioremap_caller()
> calls after ioremap_page_range().  It defaults to returning success.
> Xen PV implements it by walking the range with lookup_address() and
> failing if any entry is not present, making ioremap() return NULL.
> 
> This also affects a Xen PV dom0: an ioremap() of a range containing any
> page Xen refuses to map (e.g. MMIO Xen reserves for itself) now fails as
> a whole, rather than succeeding and faulting only when the refused page
> is accessed.  Pages Xen forces read-only are still mapped present and
> are unaffected.
> 
> Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset")

That patch is an innocent bystander, if anything - nothing it can do about Xen
being weird about not mapping host physical addresses not owned by the domain.

And TBH, all that gymnastics just to prevent this from running on Xen, is not
something that makes me all happy and so on.

What is more, we try to get rid of PV ops, not add more.

I'm sorry if I've misled you with my comment on the previous thread - I didn't
think someone would even act on it.

And I know Sean doesn't like X86_FEATURE_HYPERVISOR but sorry, nothing beats
a oneliner at the beginning of print_s5_reset_status_mmio() vs this overkill.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette