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@lists.xen.org
http://lists.xen.org/xen-devel
