linux-kernel - Re: [PATCH] XEN_DOMAIN

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1318696968.11016.47.camel@dagon.hellion.org.uk>
Date:	Sat, 15 Oct 2011 17:42:48 +0100
From:	Ian Campbell <ijc@...lion.org.uk>
To:	Konrad Rzeszutek Wilk <konrad@...nok.org>
Cc:	Maxim Uvarov <maxim.uvarov@...cle.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org,
	konrad.wilk@...cle.com
Subject: Re: [PATCH] XEN_DOMAIN_MEMORY options.

On Sat, 2011-10-15 at 09:05 -0400, Konrad Rzeszutek Wilk wrote:
> > On 10/14/2011 04:41 PM, Jeremy Fitzhardinge wrote:

> > >While it would be very silly to put 128GB of actual RAM on a 32-bit
> > >machine, systems can have non-contiguous RAM placed at high addresses,
> > >which would no longer be accessible.
> 
> Do you have some ideas of which machines that might be?

Even if you were on such a machine, the discontiguity
(discontiguousness?) wouldn't ever be reflected in the pseudo-physical
memory map, would it? So since this variable controls the maximum size
of the p2m (rather than the m2p) it doesn't need to be larger than the
maximum sane 32 bit guest size (<64G).

Ian.
-- 
Ian Campbell


Every improvement in communication makes the bore more terrible.
		-- Frank Moore Colby

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)