From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com,
Jan Beulich <JBeulich@suse.com>
Subject: Re: identify a Xen PV domU to fix devmem_is_allowed
Date: Mon, 21 Mar 2016 17:29:57 -0400 [thread overview]
Message-ID: <56F067D5.1040404@oracle.com> (raw)
In-Reply-To: <20160315165702.GA29619@gmail.com>
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
next prev parent reply other threads:[~2016-03-21 21:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-29 10:28 identify a Xen PV domU to fix devmem_is_allowed Olaf Hering
2016-02-29 15:10 ` Konrad Rzeszutek Wilk
2016-02-29 15:29 ` Olaf Hering
2016-02-29 18:32 ` Boris Ostrovsky
2016-03-01 15:14 ` Olaf Hering
2016-03-01 10:38 ` Jan Beulich
2016-03-01 14:34 ` Konrad Rzeszutek Wilk
2016-03-01 14:45 ` Boris Ostrovsky
2016-03-15 16:57 ` Olaf Hering
2016-03-15 18:56 ` Boris Ostrovsky
2016-03-21 21:29 ` Boris Ostrovsky [this message]
2016-03-22 18:37 ` Boris Ostrovsky
2016-03-23 8:28 ` Olaf Hering
2016-06-06 21:17 ` Olaf Hering
2016-03-01 16:23 ` Olaf Hering
2016-03-01 15:29 ` David Vrabel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56F067D5.1040404@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=JBeulich@suse.com \
--cc=david.vrabel@citrix.com \
--cc=olaf@aepfle.de \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).