On 03/21/2016 05:29 PM, Boris Ostrovsky wrote:
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?
Olaf,
Can you apply PAT changes from
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02127.html and
see if it helps?
It should at least get rid of the splat (patch 3 is the one addresses
no-MTRR problem that I mentioned above). We should still fix
devmem_is_allowed() though.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
