Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 03/15/2016 12:57 PM, Olaf Hering wrote:
> On Tue, Mar 01, Boris Ostrovsky wrote:
>
> > on domU:
> >
> > [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# od -N 1 -j 4096 /dev/mem
> > od: /dev/mem: read error: Bad address
> > 0010000
> > [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]#
> >
> > with
> >
> > (XEN) mm.c:1767:d14v0 Bad L1 flags 10
> How should we proceed with this bug?
I can't see any way to avoid calling xen_pv_domain() so what you 
suggested should work. The only problem is that this will now cause 
reserved areas to also return 0:
# head /proc/iomem
00000000-00000fff : reserved <====
00001000-0009ffff : System RAM
000a0000-000fffff : reserved       <=====
  000f0000-000fffff : System ROM
00100000-7fffffff : System RAM
  01000000-0172a065 : Kernel code
  0172a066-01d32b3f : Kernel data
  01ec5000-02026fff : Kernel bss
fee00000-fee00fff : Local APIC

which I don't think they really should.

How about this:

    if (pagenr < 256 && !xen_pv_domain())
        return 1;
    if (iomem_is_exclusive(pagenr << PAGE_SHIFT))
        return 0;
    if (!page_is_ram(pagenr))
        return 1;


Also, while looking into this I noticed that pat_x_mtrr_type() will make 
us switch from _PAGE_CACHE_MODE_WB to _PAGE_CACHE_MODE_UC_MINUS when 
trying to mmap and this is what causes the hypervisor error message and 
the splat in Linux. We make this switch despite the fact that MTRR is 
disabled and therefore mtrr_type_lookup() returns MTRR_TYPE_INVALID.
Should we return req_type is MTRR is disabled?

-boris





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel