All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Joerg Roedel <jroedel@suse.de>,
	David Rientjes <rientjes@google.com>,
	Borislav Petkov <bp@alien8.de>,
	Sean Christopherson <seanjc@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andi Kleen <ak@linux.intel.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Jon Grimm <jon.grimm@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	"Kaplan, David" <David.Kaplan@amd.com>,
	Varad Gautam <varad.gautam@suse.com>,
	Dario Faggioli <dfaggioli@suse.com>
Cc: x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev
Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP
Date: Mon, 19 Jul 2021 17:26:20 -0700	[thread overview]
Message-ID: <a5ac5af6-7e28-4e9c-e55b-db31842a5911@kernel.org> (raw)
In-Reply-To: <YPV27hDPZUoVsIZt@suse.de>

On 7/19/21 5:58 AM, Joerg Roedel wrote:

> Memory Validation through the Boot Process and in the Running System
> --------------------------------------------------------------------
> 
> The memory is validated throughout the boot process as described below.
> These steps assume a firmware is present, but this proposal does not
> strictly require a firmware. The tasks done be the firmware can also be
> done by the hypervisor before starting the guest. The steps are:
> 
> 	1. The firmware validates all memory which will not be owned by
> 	   the boot loader or the OS.
> 
> 	2. The firmware also validates the first X MB of memory, just
> 	   enough to run a boot loader and to load the compressed Linux
> 	   kernel image. X is not expected to be very large, 64 or 128
> 	   MB should be enough. This pre-validation should not cause
> 	   significant delays in the boot process.
> 
> 	3. The validated memory is marked E820-Usable in struct
> 	   boot_params for the Linux decompressor. The rest of the
> 	   memory is also passed to Linux via new special E820 entries
> 	   which mark the memory as Usable-but-Invalid.
> 
> 	4. When the Linux decompressor takes over control, it evaluates
> 	   the E820 table and calculates to total amount of memory
> 	   available to Linux (valid and invalid memory).
> 
> 	   The decompressor allocates a physically contiguous data
> 	   structure at a random memory location which is big enough to
> 	   hold the the validation states of all 4kb pages available to
> 	   the guest. This data structure will be called the Validation
> 	   Bitmap through the rest of this document. The Validation
> 	   Bitmap is indexed by page frame numbers. 

At the risk of asking a potentially silly question, would it be
reasonable to treat non-validated memory as not-present for kernel
purposes and hot-add it in a thread as it gets validated?  Or would this
result in poor system behavior before enough memory is validated?
Perhaps we should block instead of failing allocations if we want more
memory than is currently validated?

--Andy

  parent reply	other threads:[~2021-07-20  0:26 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 12:58 Runtime Memory Validation in Intel-TDX and AMD-SNP Joerg Roedel
2021-07-19 13:07 ` Matthew Wilcox
2021-07-19 15:02   ` Joerg Roedel
2021-07-19 20:39 ` Andi Kleen
2021-07-20  8:55   ` Joerg Roedel
2021-07-20  9:34     ` Dr. David Alan Gilbert
2021-07-20 11:50       ` Joerg Roedel
2021-07-20  0:26 ` Andy Lutomirski [this message]
2021-07-20  1:51   ` Erdem Aktas
2021-07-20  2:00     ` Erdem Aktas
2021-07-20  3:30     ` Andy Lutomirski
2021-07-20 19:54       ` Erdem Aktas
2021-07-20 22:01         ` Andi Kleen
2021-07-20 23:55           ` Erdem Aktas
2021-07-21  0:35             ` Andi Kleen
2021-07-21  8:51           ` Joerg Roedel
2021-07-20  5:17     ` Andi Kleen
2021-07-20  9:11       ` Joerg Roedel
2021-07-20 17:32         ` Andi Kleen
2021-07-20 23:09       ` Erdem Aktas
2021-07-21  0:38         ` Andi Kleen
2021-07-22 17:31       ` Marc Orr
2021-07-26 18:55         ` Joerg Roedel
2021-07-20  8:44   ` Joerg Roedel
2021-07-20 14:14   ` Dave Hansen
2021-07-20 17:30 ` Kirill A. Shutemov
2021-07-21  9:20   ` Mike Rapoport
2021-07-21 10:02     ` Kirill A. Shutemov
2021-07-21 10:22       ` Mike Rapoport
2021-07-21 10:53       ` Joerg Roedel
2021-07-21  9:25   ` Joerg Roedel
2021-07-21 10:25     ` Kirill A. Shutemov
2021-07-21 10:48       ` Joerg Roedel
2021-07-22 15:46   ` David Hildenbrand
2021-07-26 19:02     ` Joerg Roedel
2021-07-27  9:34       ` David Hildenbrand
2021-08-02 10:19         ` Joerg Roedel
2021-08-02 18:47           ` David Hildenbrand
2021-07-22 15:57 ` David Hildenbrand
2021-07-22 19:51 ` Kirill A. Shutemov
2021-07-23 15:23   ` Mike Rapoport
2021-07-23 16:29     ` Kirill A. Shutemov
2021-07-25  9:16       ` Mike Rapoport
2021-07-25 18:28         ` Kirill A. Shutemov
2021-07-26 10:00           ` Mike Rapoport
2021-07-26 11:53             ` Kirill A. Shutemov
2021-07-26 19:13   ` Joerg Roedel
2021-07-26 23:02   ` Erdem Aktas
2021-07-26 23:54     ` Kirill A. Shutemov
2021-07-27  1:35       ` Erdem Aktas
2021-07-23 11:04 ` Varad Gautam
2021-07-23 14:34   ` Kaplan, David

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a5ac5af6-7e28-4e9c-e55b-db31842a5911@kernel.org \
    --to=luto@kernel.org \
    --cc=David.Kaplan@amd.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=dfaggioli@suse.com \
    --cc=jon.grimm@amd.com \
    --cc=jroedel@suse.de \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=varad.gautam@suse.com \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.