Re: identify a Xen PV domU to fix devmem_is_allowed

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 03/01/2016 09:34 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 01, 2016 at 03:38:55AM -0700, Jan Beulich wrote:
>>>>> On 29.02.16 at 16:10, <konrad.wilk@oracle.com> wrote:
>>> On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
>>>> What is the correct way to identify a Xen PV domU in the kenrel?
>>>> devmem_is_allowed() used to disable access to pages < 256 in domU.
>>>> With pvops this check was removed, or never ported forward.
>>> CC-ing Boris and Daniel.
>>>
>>> Why is this needed? The first 640KB of memory in a guest are
>>> RAM pages with no BIOS data in it.
>> Exactly: devmem_is_allowed() is specifically meant to return true
>> if and only if the page is not RAM or otherwise special. The
>> question just is whether what Olaf suggested is also correct for
>> Dom0 - I don't recall whether the low 1Mb gets 1:1 mapped in
>> that case.

I think it is. On dom0:

root@ovs101> od -N 1 -j 4096 /dev/mem
0010000 000000
0010001
root@ovs101>


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
(XEN) mm.c:1767:d14v0 Bad L1 flags 10

in the hypervisor log.

IIUIC that's because l1_disallow_mask is more permissive for dom0.



> Would it be just better to change that code to scan the E820 instead
> of using hard-coded values?

trim_bios_range() seems to imply that some BIOSes may present <1MB area 
as RAM. We remove some chunks but not all (i.e. 4K through 640K may 
still be shown as RAM).


-boris

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