From: Dave Hansen <dave.hansen@intel.com>
To: Pavan Kumar Paluri <papaluri@amd.com>, linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Eric Van Tassell <Eric.VanTassell@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>,
Michael Roth <michael.roth@amd.com>,
"H . Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v5 0/2] nosnp sev command line support
Date: Mon, 30 Sep 2024 16:25:23 -0700 [thread overview]
Message-ID: <f751ffe7-9900-4d91-9e7a-e560777725e1@intel.com> (raw)
In-Reply-To: <20240930231102.123403-1-papaluri@amd.com>
On 9/30/24 16:11, Pavan Kumar Paluri wrote:
> Provide "nosnp" boot option via "sev=nosnp" kernel command line to
> prevent SEV-SNP[1] capable host kernel from enabling SEV-SNP and
> initializing Reverse Map Table (RMP) [1].
>
> On providing sev=nosnp via kernel command line:
> cat /sys/module/kvm_amd/parameters/sev_snp should be "N".
I don't see any mention in the changelog, cover letter or Documentation/
about why someone would want to do this.
I assume it's because of performance (walking the RMP table is non-zero
cost).
The BIOS allocates the RMP table, right? So this option presumably gets
the performance back, but not the memory. That's probably also worth
mentioning ... somewhere.
next prev parent reply other threads:[~2024-09-30 23:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 23:11 [PATCH v5 0/2] nosnp sev command line support Pavan Kumar Paluri
2024-09-30 23:11 ` [PATCH v5 1/2] x86, KVM:SVM: Move sev specific parsing into arch/x86/virt/svm Pavan Kumar Paluri
2024-09-30 23:11 ` [PATCH v5 2/2] x86 KVM:SVM: Provide "nosnp" boot option for sev kernel command line Pavan Kumar Paluri
2024-09-30 23:25 ` Dave Hansen [this message]
2024-10-01 0:09 ` [PATCH v5 0/2] nosnp sev command line support Paluri, PavanKumar
2024-10-01 0:14 ` Dave Hansen
2024-10-01 0:18 ` Paluri, PavanKumar
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=f751ffe7-9900-4d91-9e7a-e560777725e1@intel.com \
--to=dave.hansen@intel.com \
--cc=Eric.VanTassell@amd.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=papaluri@amd.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
/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