[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58abbc79-64d4-41f9-9fd2-1de7826fbbf6@linux.microsoft.com>
Date: Thu, 9 Nov 2023 17:35:39 +0100
From: Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
To: Dave Hansen <dave.hansen@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
linux-kernel@...r.kernel.org,
Michael Kelley <mhklinux@...look.com>,
Dexuan Cui <decui@...rosoft.com>
Cc: linux-hyperv@...r.kernel.org, stefan.bader@...onical.com,
tim.gardner@...onical.com, roxana.nicolescu@...onical.com,
cascardo@...onical.com, kys@...rosoft.com, haiyangz@...rosoft.com,
wei.liu@...nel.org, kirill.shutemov@...ux.intel.com,
sashal@...nel.org
Subject: Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption
info
On 09/11/2023 17:25, Dave Hansen wrote:
> On 11/9/23 08:14, Jeremi Piotrowski wrote:
> ...
>> pr_info("Memory Encryption Features active:");
>>
>> - if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
>> + if (cc_vendor == CC_VENDOR_INTEL) {
>> pr_cont(" Intel TDX\n");
>> return;
>> }
>
> Why aren't these guests setting X86_FEATURE_TDX_GUEST?
They could if we can confirm that the code gated behind
cpu_feature_enabled(X86_FEATURE_TDX_GUEST) is correct when running with TD partitioning.
It still makes sense to have these prints based on the cc_xxx abstractions.
Jeremi
Powered by blists - more mailing lists