All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kalra, Ashish" <ashish.kalra@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: thomas.lendacky@amd.com, michael.roth@amd.com, x86@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] x86/sev: Add callback to apply RMP table fixups for kexec.
Date: Wed, 24 Apr 2024 18:48:08 -0500	[thread overview]
Message-ID: <ed4cb373-e626-4b79-b692-df5ea2ca8899@amd.com> (raw)
In-Reply-To: <20240420130533.GNZiO9nShSxjxB-FQn@fat_crate.local>

Hello Boris,

> Subject: Re: [PATCH v2 2/2] x86/sev: Add callback to apply RMP table fixups for kexec.
>
> From: Ashish Kalra<ashish.kalra@amd.com>

<snip>
> Why do you keep explaining in your commit messages what a patch does?
I will fix the commit message.
>> Fixes: c3b86e61b756 ("x86/cpufeatures: Enable/unmask SEV-SNP CPU feature")
>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
>> ---
>>   arch/x86/include/asm/sev.h |  2 ++
>>   arch/x86/mm/mem_encrypt.c  |  3 +++
>>   arch/x86/virt/svm/sev.c    | 44 ++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 49 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
>> index 7f57382afee4..6600ac467cf9 100644
>> --- a/arch/x86/include/asm/sev.h
>> +++ b/arch/x86/include/asm/sev.h
>> @@ -269,6 +269,7 @@ int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 asid, bool immut
>>   int rmp_make_shared(u64 pfn, enum pg_level level);
>>   void snp_leak_pages(u64 pfn, unsigned int npages);
>>   void kdump_sev_callback(void);
>> +void snp_rmptable_e820_fixup(void);
>>   #else
>>   static inline bool snp_probe_rmptable_info(void) { return false; }
>>   static inline int snp_lookup_rmpentry(u64 pfn, bool *assigned, int *level) { return -ENODEV; }
>> @@ -282,6 +283,7 @@ static inline int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 as
>>   static inline int rmp_make_shared(u64 pfn, enum pg_level level) { return -ENODEV; }
>>   static inline void snp_leak_pages(u64 pfn, unsigned int npages) {}
>>   static inline void kdump_sev_callback(void) { }
>> +static inline void snp_rmptable_e820_fixup(void) {}
>>   #endif
>>   
>>   #endif
>> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
>> index 6f3b3e028718..765ce94e4b89 100644
>> --- a/arch/x86/mm/mem_encrypt.c
>> +++ b/arch/x86/mm/mem_encrypt.c
>> @@ -102,6 +102,9 @@ void __init mem_encrypt_setup_arch(void)
>>   	phys_addr_t total_mem = memblock_phys_mem_size();
>>   	unsigned long size;
>>   
>> +	if (cpu_feature_enabled(X86_FEATURE_SEV_SNP))
> We use CC_ATTR_HOST_SEV_SNP for host SNP support checks, including RMP
> table viability.
Ok.
>
> Also, why isn't this called in snp_init()?
>
> If there's a reason why (I think there is) put that reason as a comment
> above it why this thing needs to be called here exactly.

This callback needs to be invoked as part of setup_arch() as it needs 
e820 table to be setup in e820__memory_setup() before the callback is 
invoked and snp_init() is called from sme_enable() in kernel/head_64.S 
(startup_64), which is much before start_kernel() -> setup_arch() is 
invoked.

I will add the comment here.

>> +		snp_rmptable_e820_fixup();
> IOW, point to the comment above that function's definition.
>
>> +
>>   	if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
>>   		return;
>>   
>> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
>> index ab0e8448bb6e..d999ff7f1671 100644
>> --- a/arch/x86/virt/svm/sev.c
>> +++ b/arch/x86/virt/svm/sev.c
>> @@ -163,6 +163,50 @@ bool snp_probe_rmptable_info(void)
>>   	return true;
>>   }
>>   
>> +/*
>> + * Callback to do any RMP table fixups, needs to be called
>> + * after e820__memory_setup(), after the e820 tables are
>> + * setup/populated and before e820__reserve_resources(), before
>> + * the e820 map has been converted to the standard Linux memory
>> + * resources and e820 map is no longer used and modifying it
>> + * has no effect.
>> + */
>> +void __init snp_rmptable_e820_fixup(void)
>> +{
>> +	u64 pa;
>> +
>> +	/*
>> +	 * Handle cases where the RMP table placement in the BIOS is not 2M aligned
>> +	 * and then the kexec kernel could try to allocate from within that chunk
>> +	 * and that causes a fatal RMP fault.
> Merge this comment with the one above the function and put it all there.
Ok.
>> Check if RMP table start & end
>> +	 * physical range in e820_table is not aligned to 2MB and in that case use
>> +	 * e820__range_update() to map this range to reserved, e820__range_update()
>> +	 * nicely handles partial range update and also merges any consecutive
>> +	 * ranges of the same type.
>> +	 */
> This comment talks about what this does and is kinda obvious but then
> talks about e820__range_update() and not the other ones. Just put the
> gist of what this is supposed to do and do not explain the code step by
> step.
>
> What is really missing here and what is not really trivial is why all
> three e820 tables need updating.
I will add all these details.
>
>> +	pa = probed_rmp_base;
>> +	if (!IS_ALIGNED(pa, PMD_SIZE)) {
>> +		pa = ALIGN_DOWN(pa, PMD_SIZE);
>> +		if (e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM)) {
>> +			pr_info("Reserving start of RMP table on a 2MB boundary [0x%016llx]\n", pa);
>> +			e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
>> +			e820__range_update_kexec(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
>> +			e820__range_update_firmware(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
>> +		}
>> +	}
>> +
>> +	pa = probed_rmp_base + probed_rmp_size;
>> +	if (!IS_ALIGNED(pa, PMD_SIZE)) {
>> +		pa = ALIGN_DOWN(pa, PMD_SIZE);
>> +		if (e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM)) {
>> +			pr_info("Reserving end of RMP table on a 2MB boundary [0x%016llx]\n", pa);
>> +			e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
>> +			e820__range_update_kexec(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
>> +			e820__range_update_firmware(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
>> +		}
>> +	}
>> +}
> Ontop for less duplication:
>
> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> index be17661fee9b..118dfe61f80e 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -163,6 +163,21 @@ bool snp_probe_rmptable_info(void)
>   	return true;
>   }
>   
> +static void __init __snp_e820_tables_fixup(u64 pa)
> +{
> +	if (IS_ALIGNED(pa, PMD_SIZE))
> +		return;
> +
> +	pa = ALIGN_DOWN(pa, PMD_SIZE);
> +	if (!e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM))
> +		return;
> +
> +	pr_info("Reserving chunk of RMP table on a 2MB boundary [0x%016llx]\n", pa);
> +	e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> +	e820__range_update_kexec(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> +	e820__range_update_firmware(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> +}
> +
>   /*
>    * Callback to do any RMP table fixups, needs to be called
>    * after e820__memory_setup(), after the e820 tables are
> @@ -173,8 +188,6 @@ bool snp_probe_rmptable_info(void)
>    */
>   void __init snp_rmptable_e820_fixup(void)
>   {
> -	u64 pa;
> -
>   	/*
>   	 * Handle cases where the RMP table placement in the BIOS is not 2M aligned
>   	 * and then the kexec kernel could try to allocate from within that chunk
> @@ -184,27 +197,8 @@ void __init snp_rmptable_e820_fixup(void)
>   	 * nicely handles partial range update and also merges any consecutive
>   	 * ranges of the same type.
>   	 */
> -	pa = probed_rmp_base;
> -	if (!IS_ALIGNED(pa, PMD_SIZE)) {
> -		pa = ALIGN_DOWN(pa, PMD_SIZE);
> -		if (e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM)) {
> -			pr_info("Reserving start of RMP table on a 2MB boundary [0x%016llx]\n", pa);
> -			e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> -			e820__range_update_kexec(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> -			e820__range_update_firmware(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> -		}
> -	}
> -
> -	pa = probed_rmp_base + probed_rmp_size;
> -	if (!IS_ALIGNED(pa, PMD_SIZE)) {
> -		pa = ALIGN_DOWN(pa, PMD_SIZE);
> -		if (e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM)) {
> -			pr_info("Reserving end of RMP table on a 2MB boundary [0x%016llx]\n", pa);
> -			e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> -			e820__range_update_kexec(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> -			e820__range_update_firmware(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> -		}
> -	}
> +	__snp_e820_tables_fixup(probed_rmp_base);
> +	__snp_e820_tables_fixup(probed_rmp_base + probed_rmp_size);
>   }
>   
Thanks, Ashish

  reply	other threads:[~2024-04-24 23:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15 21:08 [PATCH v2 0/2] Apply RMP table fixups for kexec Ashish Kalra
2024-04-15 21:09 ` [PATCH v2 1/2] x86/e820: Expose API to update e820 kexec and firmware tables externally Ashish Kalra
2024-04-20 11:20   ` Borislav Petkov
2024-04-15 21:09 ` [PATCH v2 2/2] x86/sev: Add callback to apply RMP table fixups for kexec Ashish Kalra
2024-04-20 13:05   ` Borislav Petkov
2024-04-24 23:48     ` Kalra, Ashish [this message]
2024-04-26 12:58       ` Borislav Petkov
2024-04-26 14:56         ` Kalra, Ashish
2024-11-16  0:52           ` Mike Rapoport
2024-11-16  1:11             ` Kalra, Ashish
2024-04-20 11:08 ` [PATCH v2 0/2] Apply " Borislav Petkov
2024-04-24 19:10   ` Kalra, Ashish
2024-04-26 12:49     ` Borislav Petkov

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=ed4cb373-e626-4b79-b692-df5ea2ca8899@amd.com \
    --to=ashish.kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=thomas.lendacky@amd.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 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.