[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.