From: Tom Lendacky <thomas.lendacky@amd.com>
To: "Kuppuswamy,
Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>
Cc: Peter H Anvin <hpa@zytor.com>,
Dave Hansen <dave.hansen@intel.com>,
Tony Luck <tony.luck@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Andi Kleen <ak@linux.intel.com>,
Kirill Shutemov <kirill.shutemov@linux.intel.com>,
Sean Christopherson <seanjc@google.com>,
Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 04/11] x86: Introduce generic protected guest abstraction
Date: Tue, 29 Jun 2021 14:47:59 -0500 [thread overview]
Message-ID: <b19d6ab8-30ad-da4a-e1a6-77c8136c0fce@amd.com> (raw)
In-Reply-To: <4853f140-9406-6d94-1546-6545472f86da@linux.intel.com>
On 6/28/21 2:14 PM, Kuppuswamy, Sathyanarayanan wrote:
>
>
> On 6/28/21 10:52 AM, Tom Lendacky wrote:
>> On 6/18/21 5:57 PM, Kuppuswamy Sathyanarayanan wrote:
>>> +static inline bool prot_guest_has(unsigned long flag)
>>> +{
>>> + if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
>>> + return tdx_protected_guest_has(flag);
>>> + else if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
>>> + return sev_protected_guest_has(flag);
>>
>> So as I think about this, I don't think this will work if the hypervisor
>> decides to change the vendor name, right?
>
> For TDX guest, vendor name cannot be changed. It is set by TDX module and
> it is fixed as per TDX module spec.
>
>>
>> And doesn't TDX supply "IntelTDX " as a signature. I don't see where
>> the signature is used to set the CPU vendor to X86_VENDOR_INTEL.>
> We don't need to specially handle it for TDX. Generic early_identify_cpu()
> will
> set boot_cpu_data.x86_vendor as X86_VENDOR_INTEL for TDX guest. I think it is
> based on Intel in vendor string.
Hmmm..., I must be missing something then. I thought early_identify_cpu()
will read the signature, which would be "IntelTDX ", right? Then that
is be compared against the structs that register via cpu_dev_register()
which would contain the x86_vendor value. I don't see anything registering
with the "IndexTDX " signature so I don't know how you'll get an
x86_vendor value of X86_VENDOR_INTEL.
I'm probably missing something there, but it shouldn't matter for this
routine going forward.
>
>>
>> The current SEV checks to set sev_status, which is used by sme_active(),
>> sev_active, etc.) are based on the max leaf and CPUID bits, but not a
>> CPUID vendor check.
>>
>
> You also set x86_vendor id as AMD based on SEV checks?
No, we don't.
>
>> So maybe we can keep the prot_guest_has() but I think it will have to be a
>> common routine, with a "switch" statement that has supporting case element
>> that check for "sev_active() || static_cpu_has(X86_FEATURE_TDX_GUEST)",
>> etc.
>
>>> }
>>> +
>>> +bool sev_protected_guest_has(unsigned long flag)
>>> +{
>>> + switch (flag) {
>>> + case PR_GUEST_MEM_ENCRYPT:
>>> + case PR_GUEST_MEM_ENCRYPT_ACTIVE:
>>> + case PR_GUEST_UNROLL_STRING_IO:
>>> + case PR_GUEST_HOST_MEM_ENCRYPT:
>>> + return true;
>>
>> This will need to be fixed up because this function will be called for
>> baremetal and legacy guests and those properties aren't true for those
>> situations. Something like (although I'm unsure of the difference between
>> PR_GUEST_MEM_ENCRYPT and PR_GUEST_MEM_ENCRYPT_ACTIVE):
>
> MEM_ENCRYPT_ACTIVE is suggested for mem_encrypt_active() case (I think it
> means some sort of encryption is active).
>
> PR_GUEST_MEM_ENCRYPT means guest supports memory encryption (sev_active()
> case).
Yeah, this is the problem with the name having guest in everything when
there are host and guest scenarios for AMD.
We have PR_GUEST_HOST_MEM_ENCRYPT but it would look strange to have
PR_GUEST_GUEST_MEM_ENCRYPT.
>
> Yes, I can include following changes in next version.
>
>>
>> case PR_GUEST_MEM_ENCRYPT:
>> case PR_GUEST_MEM_ENCRYPT_ACTIVE:
>> return sev_active();
>> case PR_GUEST_UNROLL_STRING_IO:
>> return sev_active() && !sev_es_active();
>> case PR_GUEST_HOST_MEM_ENCRYPT:
>> return sme_active();
>>
>> But you (or I) would have to audit all of the locations where
>> mem_encrypt_active(), sme_active(), sev_active() and sev_es_active() are
>> used, to be sure the right thing is being done. And for bisectability,
>> that should probably be the first patch if you will be invoking
>> prot_guest_has() in the same location as any of the identified functions.
>>
>> Create the new helper and fixup the locations should be one (or more)
>> patches. Then add the TDX support to the helper function as a follow-on
>> patch.
>
> Can you submit a patch to replace all existing uses cases of
> mem_encrypt_active()
> ,sme_active(), sev_active() and sev_es_active() with prot_guest_has()
> calls? Since
> I cannot test any of these changes for AMD, it would be better if you
> could do it.
>
> Once you submit a tested version, I can enable these features for TDX and
> test
> and submit it separately.
>
> This patch can be split as below:
>
> 1. x86: Introduce generic protected guest abstraction patch (with below
> changes).
> - Remove all PR_GUEST flags in sev_protected_guest_has() and
> tdx_protected_guest_has().
> 2. Patch from you to use prot_guest_has() for AMD code and enable relevant
> PR_GUEST flags in sev_protected_guest_has().
> 3. Patch from me to us prot_guest_has() for TDX cases and enable relevant
> PR_GUEST flags in tdx_protected_guest_has().
>
> Agree?
So I can work on a pre-patch series. It will be purely a replacement for
the current SME/SEV calls. You'll need to add all of the TDX support in a
subsequent patch in the TDX series. Given this is a pre-patch, I will
probably reset the flag values slightly and work on the names to be less
confusing.
Thanks,
Tom
next prev parent reply other threads:[~2021-06-29 19:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-18 22:57 [PATCH v3 00/11] Add TDX Guest Support (Initial support) Kuppuswamy Sathyanarayanan
2021-06-18 22:57 ` [PATCH v3 01/11] x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT Kuppuswamy Sathyanarayanan
2021-06-18 22:57 ` [PATCH v3 02/11] x86/tdx: Introduce INTEL_TDX_GUEST config option Kuppuswamy Sathyanarayanan
2021-06-19 11:59 ` Juergen Gross
2021-06-19 17:11 ` Kuppuswamy, Sathyanarayanan
2021-06-18 22:57 ` [PATCH v3 03/11] x86/cpufeatures: Add TDX Guest CPU feature Kuppuswamy Sathyanarayanan
2021-06-18 23:39 ` Borislav Petkov
2021-06-19 0:13 ` Kuppuswamy, Sathyanarayanan
2021-06-19 6:38 ` Borislav Petkov
2021-07-15 11:56 ` Xiaoyao Li
2021-07-19 5:10 ` Kuppuswamy, Sathyanarayanan
2021-06-18 22:57 ` [PATCH v3 04/11] x86: Introduce generic protected guest abstraction Kuppuswamy Sathyanarayanan
2021-06-24 15:01 ` Borislav Petkov
2021-06-24 17:58 ` Kuppuswamy, Sathyanarayanan
2021-06-28 17:52 ` Tom Lendacky
2021-06-28 18:59 ` Tom Lendacky
2021-06-28 19:14 ` Kuppuswamy, Sathyanarayanan
2021-06-29 19:47 ` Tom Lendacky [this message]
2021-06-18 22:57 ` [PATCH v3 05/11] x86/tdx: Add __tdx_module_call() and __tdx_hypercall() helper functions Kuppuswamy Sathyanarayanan
2021-06-18 22:57 ` [PATCH v3 06/11] x86/tdx: Get TD execution environment information via TDINFO Kuppuswamy Sathyanarayanan
2021-06-18 22:57 ` [PATCH v3 07/11] x86/traps: Add #VE support for TDX guest Kuppuswamy Sathyanarayanan
2021-06-18 22:57 ` [PATCH v3 08/11] x86/tdx: Add HLT " Kuppuswamy Sathyanarayanan
2021-06-18 22:57 ` [PATCH v3 09/11] x86/tdx: Wire up KVM hypercalls Kuppuswamy Sathyanarayanan
2021-06-18 22:57 ` [PATCH v3 10/11] x86/tdx: Add MSR support for TDX guest Kuppuswamy Sathyanarayanan
2021-06-18 22:57 ` [PATCH v3 11/11] x86/tdx: Handle CPUID via #VE Kuppuswamy Sathyanarayanan
2021-06-30 23:22 ` [PATCH v3 00/11] Add TDX Guest Support (Initial support) Sathyanarayanan Kuppuswamy Natarajan
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=b19d6ab8-30ad-da4a-e1a6-77c8136c0fce@amd.com \
--to=thomas.lendacky@amd.com \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=knsathya@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.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;
as well as URLs for NNTP newsgroup(s).