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

[Borislav Petkov <bp@alien8.de>]

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