mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Gupta, Pankaj" <pankaj.gupta@amd.com>
To: Tianyu Lan <ltykernel@gmail.com>,
	luto@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
	hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com,
	jgross@suse.com, tiala@microsoft.com, kirill@shutemov.name,
	jiangshan.ljs@antgroup.com, peterz@infradead.org,
	ashish.kalra@amd.com, srutherford@google.com,
	akpm@linux-foundation.org, anshuman.khandual@arm.com,
	pawan.kumar.gupta@linux.intel.com, adrian.hunter@intel.com,
	daniel.sneddon@linux.intel.com,
	alexander.shishkin@linux.intel.com, sandipan.das@amd.com,
	ray.huang@amd.com, brijesh.singh@amd.com, michael.roth@amd.com,
	thomas.lendacky@amd.com, venu.busireddy@oracle.com,
	sterritt@google.com, tony.luck@intel.com,
	samitolvanen@google.com, fenghua.yu@intel.com
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	linux-hyperv@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [RFC PATCH V2 01/18] x86/sev: Pvalidate memory gab for decompressing kernel
Date: Tue, 6 Dec 2022 10:16:03 +0100	[thread overview]
Message-ID: <eee97d32-09ea-b5d0-f45a-51c0e1d18d55@amd.com> (raw)
In-Reply-To: <20221119034633.1728632-2-ltykernel@gmail.com>

Hi Tianyu,

Some minor nits below.

> Pvalidate needed pages for decompressing kernel. The E820_TYPE_RAM
> entry includes only validated memory. The kernel expects that the
> RAM entry's addr is fixed while the entry size is to be extended
> to cover addresses to the start of next entry. This patch increases
> the RAM entry size to cover all possilble memory addresses until

s/possilble/possible

> init_size.
> 
> Signed-off-by: Tianyu Lan <tiala@microsoft.com>
> ---
>   arch/x86/boot/compressed/head_64.S |  8 +++
>   arch/x86/boot/compressed/sev.c     | 84 ++++++++++++++++++++++++++++++
>   2 files changed, 92 insertions(+)
> 
> diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
> index d33f060900d2..818edaf5d0cf 100644
> --- a/arch/x86/boot/compressed/head_64.S
> +++ b/arch/x86/boot/compressed/head_64.S
> @@ -348,6 +348,14 @@ SYM_CODE_START(startup_64)
>   	cld
>   	cli
>   
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
> +	/* pvalidate memory on demand if SNP is enabled. */
> +	pushq	%rsi
> +	movq    %rsi, %rdi
> +	call 	pvalidate_for_startup_64
> +	popq	%rsi
> +#endif
> +
>   	/* Setup data segments. */
>   	xorl	%eax, %eax
>   	movl	%eax, %ds
> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
> index 960968f8bf75..3a5a1ab16095 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -12,8 +12,10 @@
>    */
>   #include "misc.h"
>   
> +#include <asm/msr-index.h>
>   #include <asm/pgtable_types.h>
>   #include <asm/sev.h>
> +#include <asm/svm.h>
>   #include <asm/trapnr.h>
>   #include <asm/trap_pf.h>
>   #include <asm/msr-index.h>
> @@ -21,6 +23,7 @@
>   #include <asm/ptrace.h>
>   #include <asm/svm.h>
>   #include <asm/cpuid.h>
> +#include <asm/e820/types.h>
>   
>   #include "error.h"
>   #include "../msr.h"
> @@ -117,6 +120,22 @@ static enum es_result vc_read_mem(struct es_em_ctxt *ctxt,
>   /* Include code for early handlers */
>   #include "../../kernel/sev-shared.c"
>   
> +/* Check SEV-SNP via MSR */
> +static bool sev_snp_runtime_check(void)
> +{
> +	unsigned long low, high;
> +	u64 val;
> +
> +	asm volatile("rdmsr\n" : "=a" (low), "=d" (high) :
> +			"c" (MSR_AMD64_SEV));
> +
> +	val = (high << 32) | low;
> +	if (val & MSR_AMD64_SEV_SNP_ENABLED)
> +		return true;
> +
> +	return false;
> +}
> +
>   static inline bool sev_snp_enabled(void)
>   {
>   	return sev_status & MSR_AMD64_SEV_SNP_ENABLED;
> @@ -456,3 +475,68 @@ void sev_prep_identity_maps(unsigned long top_level_pgt)
>   
>   	sev_verify_cbit(top_level_pgt);
>   }
> +
> +static void extend_e820_on_demand(struct boot_e820_entry *e820_entry,
> +				  u64 needed_ram_end)
> +{
> +	u64 end, paddr;
> +	unsigned long eflags;
> +	int rc;
> +
> +	if (!e820_entry)
> +		return;
> +
> +	/* Validated memory must be aligned by PAGE_SIZE. */
> +	end = ALIGN(e820_entry->addr + e820_entry->size, PAGE_SIZE);
> +	if (needed_ram_end > end && e820_entry->type == E820_TYPE_RAM) {

maybe "if check" can be used to return from here, would read code better?

> +		for (paddr = end; paddr < needed_ram_end; paddr += PAGE_SIZE) 
Maybe we could reuse 'pvalidate_pages' here?

> +			rc = pvalidate(paddr, RMP_PG_SIZE_4K, true);
> +			if (rc) {
> +				error("Failed to validate address.n");

Would it make sense to print the cause of failure here?

> +				return;
> +			}
> +		}
> +		e820_entry->size = needed_ram_end - e820_entry->addr;
> +	}
> +}
> +
> +/*
> + * Explicitly pvalidate needed pages for decompressing the kernel.
> + * The E820_TYPE_RAM entry includes only validated memory. The kernel
> + * expects that the RAM entry's addr is fixed while the entry size is to be
> + * extended to cover addresses to the start of next entry.
> + * The function increases the RAM entry size to cover all possible memory
> + * addresses until init_size.
> + * For example,  init_end = 0x4000000,
> + * [RAM: 0x0 - 0x0],                       M[RAM: 0x0 - 0xa0000]
> + * [RSVD: 0xa0000 - 0x10000]                [RSVD: 0xa0000 - 0x10000]
> + * [ACPI: 0x10000 - 0x20000]      ==>       [ACPI: 0x10000 - 0x20000]
> + * [RSVD: 0x800000 - 0x900000]              [RSVD: 0x800000 - 0x900000]
> + * [RAM: 0x1000000 - 0x2000000]            M[RAM: 0x1000000 - 0x2001000]
> + * [RAM: 0x2001000 - 0x2007000]            M[RAM: 0x2001000 - 0x4000000]
> + * Other RAM memory after init_end is pvalidated by ms_hyperv_init_platform
> + */
> +__visible void pvalidate_for_startup_64(struct boot_params *boot_params)
> +{
> +	struct boot_e820_entry *e820_entry;
> +	u64 init_end =
> +		boot_params->hdr.pref_address + boot_params->hdr.init_size;
> +	u8 i, nr_entries = boot_params->e820_entries;
> +	u64 needed_end;

Could not very well interpret the name 'needed_end'.

> +
> +	if (!sev_snp_runtime_check())
> +		return;
> +
> +	for (i = 0; i < nr_entries; ++i) {
> +		/* Pvalidate memory holes in e820 RAM entries. */

Pvalidate and pvalidate names are used interchangeably in comments.

> +		e820_entry = &boot_params->e820_table[i];
> +		if (i < nr_entries - 1) {
> +			needed_end = boot_params->e820_table[i + 1].addr;
> +			if (needed_end < e820_entry->addr)
> +				error("e820 table is not sorted.\n");
> +		} else {
> +			needed_end = init_end;
> +		}
> +		extend_e820_on_demand(e820_entry, needed_end);
> +	}
> +}


  parent reply	other threads:[~2022-12-06  9:17 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-19  3:46 [RFC PATCH V2 00/18] x86/hyperv/sev: Add AMD sev-snp enlightened guest support on hyperv Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 01/18] x86/sev: Pvalidate memory gab for decompressing kernel Tianyu Lan
2022-11-29 12:56   ` Borislav Petkov
2022-11-29 14:42     ` Tianyu Lan
2022-11-29 15:22       ` Borislav Petkov
2022-12-28 19:15       ` Michael Kelley (LINUX)
2022-12-06  9:16   ` Gupta, Pankaj [this message]
2022-12-08 13:04     ` Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 02/18] x86/hyperv: Add sev-snp enlightened guest specific config Tianyu Lan
2022-12-12 17:56   ` Michael Kelley (LINUX)
2022-12-13  9:58     ` Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 03/18] x86/hyperv: apic change for sev-snp enlightened guest Tianyu Lan
2022-12-12 19:00   ` Michael Kelley (LINUX)
2022-11-19  3:46 ` [RFC PATCH V2 04/18] x86/hyperv: Decrypt hv vp assist page in " Tianyu Lan
2022-12-12 19:41   ` Michael Kelley (LINUX)
2022-12-13 15:21     ` Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 05/18] x86/hyperv: Get Virtual Trust Level via hvcall Tianyu Lan
2022-12-12 23:41   ` Michael Kelley (LINUX)
2022-11-19  3:46 ` [RFC PATCH V2 06/18] x86/hyperv: Use vmmcall to implement hvcall in sev-snp enlightened guest Tianyu Lan
2022-12-13 17:19   ` Michael Kelley (LINUX)
2022-12-14 16:02     ` Tianyu Lan
2023-01-09  7:24   ` Dexuan Cui
2022-11-19  3:46 ` [RFC PATCH V2 07/18] clocksource: hyper-v: decrypt hyperv tsc page " Tianyu Lan
2022-12-13 17:30   ` Michael Kelley (LINUX)
2022-12-14 16:05     ` Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 08/18] x86/hyperv: decrypt vmbus pages for " Tianyu Lan
2022-12-13 18:08   ` Michael Kelley (LINUX)
2022-12-26  4:19     ` Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 09/18] x86/hyperv: set target vtl in the vmbus init message Tianyu Lan
2022-12-14 18:12   ` Michael Kelley (LINUX)
2022-11-19  3:46 ` [RFC PATCH V2 10/18] drivers: hv: Decrypt percpu hvcall input arg page in sev-snp enlightened guest Tianyu Lan
2022-12-08 21:52   ` Dexuan Cui
2022-12-09  2:26     ` Tianyu Lan
2022-12-14 18:16   ` Michael Kelley (LINUX)
2022-12-26  7:26     ` Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 11/18] Drivers: hv: vmbus: Decrypt vmbus ring buffer Tianyu Lan
2022-12-14 18:25   ` Michael Kelley (LINUX)
2022-12-26  7:59     ` Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 12/18] x86/hyperv: Initialize cpu and memory for sev-snp enlightened guest Tianyu Lan
2022-12-28 17:07   ` Michael Kelley (LINUX)
2022-11-19  3:46 ` [RFC PATCH V2 13/18] x86/hyperv: Add smp support for sev-snp guest Tianyu Lan
2022-12-28 18:14   ` Michael Kelley (LINUX)
2022-11-19  3:46 ` [RFC PATCH V2 14/18] x86/hyperv: Add hyperv-specific hadling for VMMCALL under SEV-ES Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 15/18] x86/sev: Add a #HV exception handler Tianyu Lan
2023-01-10 12:47   ` Gupta, Pankaj
2023-01-10 13:43     ` Tianyu Lan
2023-01-12  7:43       ` Gupta, Pankaj
2022-11-19  3:46 ` [RFC PATCH V2 16/18] x86/sev: Initialize #HV doorbell and handle interrupt requests Tianyu Lan
2022-11-21 15:05   ` Kalra, Ashish
2022-11-22 13:46     ` Tianyu Lan
2022-11-22 19:17       ` Kalra, Ashish
2022-11-23 18:36   ` Tom Lendacky
2022-11-25  3:36     ` Tianyu Lan
2022-11-25 11:49   ` Christophe de Dinechin
2022-11-28  5:47     ` Tianyu Lan
2022-12-07 14:13   ` Gupta, Pankaj
2022-12-08 14:21     ` Tianyu Lan
2022-12-08 14:36       ` Gupta, Pankaj
2022-12-08 11:47   ` Gupta, Pankaj
2022-12-08 14:25     ` Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 17/18] x86/sev: optimize system vector processing invoked from #HV exception Tianyu Lan
2022-11-19  3:46 ` [RFC PATCH V2 18/18] x86/sev: Fix interrupt exit code paths " Tianyu Lan
2022-12-13  7:37   ` Gupta, Pankaj

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=eee97d32-09ea-b5d0-f45a-51c0e1d18d55@amd.com \
    --to=pankaj.gupta@amd.com \
    --cc=adrian.hunter@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ashish.kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=daniel.sneddon@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=jiangshan.ljs@antgroup.com \
    --cc=kirill@shutemov.name \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltykernel@gmail.com \
    --cc=luto@kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=ray.huang@amd.com \
    --cc=samitolvanen@google.com \
    --cc=sandipan.das@amd.com \
    --cc=seanjc@google.com \
    --cc=srutherford@google.com \
    --cc=sterritt@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tiala@microsoft.com \
    --cc=tony.luck@intel.com \
    --cc=venu.busireddy@oracle.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®