linux-kernel - Re: [PATCH 00/10] Introduce guestmemfs: persistent in-memory filesystem

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: <cc168bf913aaf9bb11fb31d0f5a6c3d453a38942.camel@amazon.com>
Date: Mon, 5 Aug 2024 19:53:34 +0000
From: "Gowans, James" <jgowans@...zon.com>
To: "tytso@....edu" <tytso@....edu>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "rppt@...nel.org"
	<rppt@...nel.org>, "brauner@...nel.org" <brauner@...nel.org>, "Graf (AWS),
 Alexander" <graf@...zon.de>, "anthony.yznaga@...cle.com"
	<anthony.yznaga@...cle.com>, "steven.sistare@...cle.com"
	<steven.sistare@...cle.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"Woodhouse, David" <dwmw@...zon.co.uk>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"nh-open-source@...zon.com" <nh-open-source@...zon.com>, "Saenz Julienne,
 Nicolas" <nsaenz@...zon.es>, "Durrant, Paul" <pdurrant@...zon.co.uk>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>, "jack@...e.cz"
	<jack@...e.cz>, "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>, "jgg@...pe.ca" <jgg@...pe.ca>,
	"usama.arif@...edance.com" <usama.arif@...edance.com>
Subject: Re: [PATCH 00/10] Introduce guestmemfs: persistent in-memory filesystem

On Mon, 2024-08-05 at 10:32 -0400, Theodore Ts'o wrote:
> On Mon, Aug 05, 2024 at 11:32:35AM +0200, James Gowans wrote:
> > Guestmemfs implements preservation acrosss kexec by carving out a
> > large contiguous block of host system RAM early in boot which is
> > then used as the data for the guestmemfs files.
> 
> Why does the memory have to be (a) contiguous, and (b) carved out of
> *host* system memory early in boot?  This seems to be very inflexible;
> it means that you have to know how much memory will be needed for
> guestmemfs in early boot.

The main reason for both of these is to guarantee that the huge (2 MiB
PMD) and gigantic (1 GiB PUD) allocations can happen. While this patch
series only does huge page allocations for simplicity, the intention is
to extend it to gigantic PUD level allocations soon (I'd like to get the
simple functionality merged before adding more complexity).
Other than doing a memblock allocation at early boot there really is no
way that I know of to do GiB-size allocations dynamically.

In terms of the need for a contiguous chunk, that's a bit of a
simplification for now. As mentioned in the cover letter there currently
isn't any NUMA support in this patch series. We'd want to add the
ability to do NUMA handling in following patch series. In that case it
would be multiple contiguous allocations, one for each NUMA node that
the user wants to run VMs on.

JG