From: "Kalra, Ashish" <ashish.kalra@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: bp@kernel.org, thomas.lendacky@amd.com,
linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org,
michael.roth@amd.com, x86@kernel.org
Subject: Re: [PATCH] x86/sev: Apply RMP table fixups for kexec.
Date: Tue, 2 Apr 2024 16:00:03 -0500 [thread overview]
Message-ID: <6fdb98f8-b4e2-474d-b8e9-c3092e77e56e@amd.com> (raw)
In-Reply-To: <20240402202118.GCZgxovu-pgPKYvner@fat_crate.local>
On 4/2/2024 3:21 PM, Borislav Petkov wrote:
> On Tue, Apr 02, 2024 at 02:33:44PM -0500, Kalra, Ashish wrote:
>> And we can't do this in snp_rmptable_init() as e820_table_firmware can't be
>> fixed at that point and by that time this table has been mapped into sysfs
>> (/sys/firmware) which is used by kexec -c variant.
> Well, you have to do something here because if snp_rmptable_init()
> late-disables SNP, your RMP table fixups are moot and invalid.
>
> Which means, your RMP table fixups need to happen at the *very* *late*
> step after we know that SNP is enabled and won't get disabled anymore.
>
> I.e., in snp_rmptable_init().
The main issue with doing that in snp_rmptable_init() is that there is
no e820 API interfaces available to update the e820_table_kexec and
e820_table_firmware and e820_table_firmware has already been exposed to
sysfs.
The e820 API only exports e820__range_update() which *only* fixes
e820_table.
The important point to note here is that in most cases BIOS would have
reserved RMP table start and end aligned to 2M boundary and setup the
e820 table which the BIOS passes to the kernel as such, so even if the
kernel does not enable SNP or disables SNP later, these reservations
will remain aligned as such. So what we are doing here in-kernel fixups
is doing the same alignment fixups which the BIOS would have done. The
summary here is that e820 table adjustments for RMP table done either by
BIOS and/or kernel will exist/remain even if SNP is not enabled by the
kernel.
Thanks, Ashish
next prev parent reply other threads:[~2024-04-02 21:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-12 18:47 [PATCH] x86/sev: Apply RMP table fixups for kexec Ashish Kalra
2024-03-13 10:58 ` Aithal, Srikanth
2024-04-02 14:45 ` bp
2024-04-02 15:54 ` Tom Lendacky
2024-04-02 16:34 ` bp
2024-04-02 17:06 ` Kalra, Ashish
2024-04-02 17:11 ` Kalra, Ashish
2024-04-02 17:45 ` Borislav Petkov
2024-04-02 18:41 ` Kalra, Ashish
2024-04-02 18:50 ` Borislav Petkov
2024-04-02 19:33 ` Kalra, Ashish
2024-04-02 20:21 ` Borislav Petkov
2024-04-02 21:00 ` Kalra, Ashish [this message]
2024-04-02 21:17 ` Kalra, Ashish
2024-04-02 21:20 ` Borislav Petkov
2024-04-02 21:31 ` Kalra, Ashish
2024-04-02 21:40 ` Borislav Petkov
2024-04-02 22:09 ` Tom Lendacky
2024-04-02 22:31 ` Kalra, Ashish
2024-04-02 22:42 ` Michael Roth
2024-04-03 21:08 ` Kalra, Ashish
2024-04-04 8:17 ` Jeremi Piotrowski
2024-04-04 18:07 ` Kalra, Ashish
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=6fdb98f8-b4e2-474d-b8e9-c3092e77e56e@amd.com \
--to=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=bp@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox