From: Tom Lendacky <thomas.lendacky@amd.com>
To: "Nikunj A. Dadhania" <nikunj@amd.com>,
linux-kernel@vger.kernel.org, x86@kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Michael Roth <michael.roth@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>
Subject: Re: [PATCH v3 1/8] x86/sev: Prepare for using the RMPREAD instruction to access the RMP
Date: Wed, 16 Oct 2024 09:43:56 -0500 [thread overview]
Message-ID: <9fb4543c-c876-3f82-f1a9-306e4f35d8dc@amd.com> (raw)
In-Reply-To: <85583be0-5e8a-82ce-a134-95fe9d85a2a7@amd.com>
On 10/16/24 03:52, Nikunj A. Dadhania wrote:
> On 9/30/2024 8:52 PM, Tom Lendacky wrote:
>> The RMPREAD instruction returns an architecture defined format of an
>> RMP entry. This is the preferred method for examining RMP entries.
>>
>> In preparation for using the RMPREAD instruction, convert the existing
>> code that directly accesses the RMP to map the raw RMP information into
>> the architecture defined format.
>>
>> RMPREAD output returns a status bit for the 2MB region status. If the
>> input page address is 2MB aligned and any other pages within the 2MB
>> region are assigned, then 2MB region status will be set to 1. Otherwise,
>> the 2MB region status will be set to 0. For systems that do not support
>> RMPREAD, calculating this value would require looping over all of the RMP
>> table entries within that range until one is found with the assigned bit
>> set. Since this bit is not defined in the current format, and so not used
>> today, do not incur the overhead associated with calculating it.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>> arch/x86/virt/svm/sev.c | 141 ++++++++++++++++++++++++++++------------
>> 1 file changed, 98 insertions(+), 43 deletions(-)
>>
>> -static struct rmpentry *get_rmpentry(u64 pfn)
>> +static struct rmpentry_raw *__get_rmpentry(unsigned long pfn)
>
> pfn type has changed from u64 => unsigned long, is this intentional ?
No, not intentional, I'm just used to pfn's being unsigned longs... good
catch.
>
>> +static int __snp_lookup_rmpentry(u64 pfn, struct rmpentry *entry, int *level)
>> +{
>> + struct rmpentry large_entry;
>> + int ret;
>> +
>> + if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP))
>> + return -ENODEV;
>
> Can we rely on rmp_table check in __get_rmpentry() and remove the above check ?
> If rmp_table is NULL, CC_ATTR_HOST_SEV_SNP is always cleared.
I'm trying to not change the logic and just add the new struct usage.
Once RMPREAD is used there is no checking of the table address and if
SNP is not enabled in the SYSCFG MSR the instruction will #UD.
The table address check is just to ensure we don't accidentally call
this function without checking CC_ATTR_HOST_SEV_SNP in the future to
avoid a possible crash. If anything, I can remove the table address
check that I added here, but I would like to keep it just to be safe.
Thanks,
Tom
>
>> +
>> + ret = get_rmpentry(pfn, entry);
>> + if (ret)
>> + return ret;
>
> Regards
> Nikunj
next prev parent reply other threads:[~2024-10-16 14:44 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 15:22 [PATCH v3 0/8] Provide support for RMPREAD and a segmented RMP Tom Lendacky
2024-09-30 15:22 ` [PATCH v3 1/8] x86/sev: Prepare for using the RMPREAD instruction to access the RMP Tom Lendacky
2024-10-16 8:52 ` Nikunj A. Dadhania
2024-10-16 14:43 ` Tom Lendacky [this message]
2024-10-17 5:24 ` Nikunj A. Dadhania
2024-10-16 15:01 ` Neeraj Upadhyay
2024-09-30 15:22 ` [PATCH v3 2/8] x86/sev: Add support for the RMPREAD instruction Tom Lendacky
2024-10-16 10:46 ` Nikunj A. Dadhania
2024-10-17 15:26 ` Borislav Petkov
2024-10-17 16:24 ` Tom Lendacky
2024-10-18 4:21 ` Neeraj Upadhyay
2024-10-18 12:41 ` Borislav Petkov
2024-10-18 15:14 ` Tom Lendacky
2024-10-21 15:41 ` Borislav Petkov
2024-10-21 17:10 ` Tom Lendacky
2024-10-21 17:49 ` Borislav Petkov
2024-09-30 15:22 ` [PATCH v3 3/8] x86/sev: Require the RMPREAD instruction after Fam19h Tom Lendacky
2024-09-30 17:03 ` Dave Hansen
2024-09-30 18:59 ` Tom Lendacky
2024-10-18 13:06 ` Borislav Petkov
2024-10-18 4:26 ` Neeraj Upadhyay
2024-10-18 13:30 ` Tom Lendacky
2024-09-30 15:22 ` [PATCH v3 4/8] x86/sev: Move the SNP probe routine out of the way Tom Lendacky
2024-10-16 11:05 ` Nikunj A. Dadhania
2024-10-18 4:28 ` Neeraj Upadhyay
2024-09-30 15:22 ` [PATCH v3 5/8] x86/sev: Map only the RMP table entries instead of the full RMP range Tom Lendacky
2024-10-16 11:25 ` [sos-linux-ext-patches] " Nikunj A. Dadhania
2024-10-18 4:38 ` Neeraj Upadhyay
2024-10-18 13:32 ` Tom Lendacky
2024-09-30 15:22 ` [PATCH v3 6/8] x86/sev: Treat the contiguous RMP table as a single RMP segment Tom Lendacky
2024-10-17 11:05 ` Nikunj A. Dadhania
2024-10-18 5:59 ` Neeraj Upadhyay
2024-10-18 13:56 ` Tom Lendacky
2024-10-18 14:42 ` Tom Lendacky
2024-09-30 15:22 ` [PATCH v3 7/8] x86/sev: Add full support for a segmented RMP table Tom Lendacky
2024-10-18 6:32 ` Nikunj A. Dadhania
2024-10-18 14:41 ` Tom Lendacky
2024-10-18 8:37 ` Neeraj Upadhyay
2024-10-18 15:06 ` Tom Lendacky
2024-09-30 15:22 ` [PATCH v3 8/8] x86/sev/docs: Document the SNP Reverse Map Table (RMP) Tom Lendacky
2024-10-18 6:56 ` Nikunj A. Dadhania
2024-10-18 14:48 ` Tom Lendacky
2024-10-18 13:31 ` Neeraj Upadhyay
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=9fb4543c-c876-3f82-f1a9-306e4f35d8dc@amd.com \
--to=thomas.lendacky@amd.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=tglx@linutronix.de \
--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®