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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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