linux-kernel - Re: [Xen-devel] [PATCH 0/2] xen: Switch to virtual mapped linear p2m list

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1414489898.23883.25.camel@citrix.com>
Date:	Tue, 28 Oct 2014 09:51:38 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Juergen Gross <jgross@...e.com>
CC:	David Vrabel <david.vrabel@...rix.com>,
	<linux-kernel@...r.kernel.org>, <xen-devel@...ts.xensource.com>,
	<konrad.wilk@...cle.com>, <boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] [PATCH 0/2] xen: Switch to virtual mapped linear
 p2m list

On Tue, 2014-10-28 at 06:00 +0100, Juergen Gross wrote:
> On 10/27/2014 04:16 PM, David Vrabel wrote:
> > On 27/10/14 14:52, Juergen Gross wrote:
> >> Paravirtualized kernels running on Xen use a three level tree for
> >> translation of guest specific physical addresses to machine global
> >> addresses. This p2m tree is used for construction of page table
> >> entries, so the p2m tree walk is performance critical.
> >>
> >> By using a linear virtual mapped p2m list accesses to p2m elements
> >> can be sped up while even simplifying code. To achieve this goal
> >> some p2m related initializations have to be performed later in the
> >> boot process, as the final p2m list can be set up only after basic
> >> memory management functions are available.
> >
> > What impact does this have on 32-bit guests which don't have huge amount
> > of virtual address space?
> >
> > I think a 32-bit guest could have up to 64 GiB of PFNs, which would
> > require a 128 MiB p2m array, which is too large?
> 
> It is 64 MB (one entry on 32 bit is 32 bits :-) ).
> 
> With a m2p array of only 16 MB size I doubt a 32 bit guest can be larger
> than 16 GB, or am I wrong here?

I think they can be bigger, the compat r/o m2p is 168MB, since Xen
doesn't need to be in the hole as well (like it was with a real 32-bit
Xen). There is also some scope for dynamic sizing of the hole (queried
via XENMEM_machphys_mapping), I'm not sure if pvops makes use of that
though.

In practice a 32-bit kernel starts to get pretty unhappy somewhere
between 32 and 64GB because it runs out of low memory for various
structures which are sized according to the amount of RAM. Or it did,
it's been years since I've tried, maybe things are more able to use
highmem now. In any case if you have such large amounts of RAM using a
64-bit kernel would be advisable.

Ian.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/