IO just fine, and that it's perfectly reasonable for a KVM-based VMM
to emulate the chipset, assuming a guest doesn't have access to some asset is simply
wrong.

But rather than play whack-a-mole, can't we deal with the ignore PTE write failures
in ioremap()?  E.g. something like this?

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 12c8180ca1ba..b7e2c752af1d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -29,6 +29,8 @@
 #include <asm/memtype.h>
 #include <asm/setup.h>
 
+#include <xen/xen.h>
+
 #include "physaddr.h"
 
 /*
@@ -301,6 +303,20 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
        if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot))
                goto err_free_area;
 
+       /*
+        * Verify the range was actually mapped when running as a Xen PV DomU
+        * guest.  Xen PV doesn't emulate a virtual chipset/motherboard, and
+        * disallows DomU from mapping host physical addresses that the domain
+        * doesn't own.  Unfortunately, the PTE APIs assume success, and so
+        * Xen's rejection of the mapping is ignored.
+        */
+       if (xen_pv_domain() && !xen_initial_domain()) {
+               int level;
+
+               if (!lookup_address(vaddr, &level))
+                       goto err_free_area;
+       }
+
        ret_addr = (void __iomem *) (vaddr + offset);
        mmiotrace_ioremap(unaligned_phys_addr, unaligned_size, ret_addr);[PATCH] x86/CPU/AMD: avoid printing reset reasons on Xen domUSean Christopherson <seanjc@google.com> undefinedAndrew Cooper <andrew.cooper3@citrix.com> undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined undefined