From: Jason Andryuk <jason.andryuk@amd.com>
To: Juergen Gross <jgross@suse.com>,
Ajay Kaher <ajay.kaher@broadcom.com>,
Alexey Makhalov <alexey.makhalov@broadcom.com>,
"Broadcom internal kernel review list"
<bcm-kernel-feedback-list@broadcom.com>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Yazen Ghannam <yazen.ghannam@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>
Cc: Jason Andryuk <jason.andryuk@amd.com>,
Sean Christopherson <seanjc@google.com>,
Ingo Molnar <mingo@kernel.org>, <virtualization@lists.linux.dev>,
<linux-kernel@vger.kernel.org>, <xen-devel@lists.xenproject.org>
Subject: [PATCH] x86/paravirt: Add ioremap_verify_range hook and implement it for Xen PV
Date: Fri, 30 Oct 2026 20:33:08 -0400 [thread overview]
Message-ID: <20261031003309.3751-1-jason.andryuk@amd.com> (raw)
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
next reply other threads:[~2026-10-31 0:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-31 0:33 Jason Andryuk [this message]
2026-10-31 0:45 ` [PATCH] x86/paravirt: Add ioremap_verify_range hook and implement it for Xen PV sashiko-bot
2026-10-31 3:20 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261031003309.3751-1-jason.andryuk@amd.com \
--to=jason.andryuk@amd.com \
--cc=ajay.kaher@broadcom.com \
--cc=alexey.makhalov@broadcom.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=tglx@kernel.org \
--cc=virtualization@lists.linux.dev \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
--cc=yazen.ghannam@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.