| Message ID | 3a1c9807d8c140bdd550cd5736664f86782cca64.1655894131.git.kai.huang@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | TDX host kernel support | expand |
On Wed, Jun 22, 2022 at 11:16:07PM +1200, Kai Huang wrote: >-static bool intel_cc_platform_has(enum cc_attr attr) >+#ifdef CONFIG_INTEL_TDX_GUEST >+static bool intel_tdx_guest_has(enum cc_attr attr) > { > switch (attr) { > case CC_ATTR_GUEST_UNROLL_STRING_IO: >@@ -28,6 +31,33 @@ static bool intel_cc_platform_has(enum cc_attr attr) > return false; > } > } >+#endif >+ >+#ifdef CONFIG_INTEL_TDX_HOST >+static bool intel_tdx_host_has(enum cc_attr attr) >+{ >+ switch (attr) { >+ case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: >+ case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: >+ return true; >+ default: >+ return false; >+ } >+} >+#endif >+ >+static bool intel_cc_platform_has(enum cc_attr attr) >+{ >+#ifdef CONFIG_INTEL_TDX_GUEST >+ if (boot_cpu_has(X86_FEATURE_TDX_GUEST)) >+ return intel_tdx_guest_has(attr); >+#endif >+#ifdef CONFIG_INTEL_TDX_HOST >+ if (platform_tdx_enabled()) >+ return intel_tdx_host_has(attr); >+#endif >+ return false; >+} how about: static bool intel_cc_platform_has(enum cc_attr attr) { switch (attr) { /* attributes applied to TDX guest only */ case CC_ATTR_GUEST_UNROLL_STRING_IO: ... return boot_cpu_has(X86_FEATURE_TDX_GUEST); /* attributes applied to TDX host only */ case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: return platform_tdx_enabled(); default: return false; } } so that we can get rid of #ifdef/endif.
On Fri, 2022-06-24 at 09:41 +0800, Chao Gao wrote: > On Wed, Jun 22, 2022 at 11:16:07PM +1200, Kai Huang wrote: > > -static bool intel_cc_platform_has(enum cc_attr attr) > > +#ifdef CONFIG_INTEL_TDX_GUEST > > +static bool intel_tdx_guest_has(enum cc_attr attr) > > { > > switch (attr) { > > case CC_ATTR_GUEST_UNROLL_STRING_IO: > > @@ -28,6 +31,33 @@ static bool intel_cc_platform_has(enum cc_attr attr) > > return false; > > } > > } > > +#endif > > + > > +#ifdef CONFIG_INTEL_TDX_HOST > > +static bool intel_tdx_host_has(enum cc_attr attr) > > +{ > > + switch (attr) { > > + case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: > > + case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: > > + return true; > > + default: > > + return false; > > + } > > +} > > +#endif > > + > > +static bool intel_cc_platform_has(enum cc_attr attr) > > +{ > > +#ifdef CONFIG_INTEL_TDX_GUEST > > + if (boot_cpu_has(X86_FEATURE_TDX_GUEST)) > > + return intel_tdx_guest_has(attr); > > +#endif > > +#ifdef CONFIG_INTEL_TDX_HOST > > + if (platform_tdx_enabled()) > > + return intel_tdx_host_has(attr); > > +#endif > > + return false; > > +} > > how about: > > static bool intel_cc_platform_has(enum cc_attr attr) > { > switch (attr) { > /* attributes applied to TDX guest only */ > case CC_ATTR_GUEST_UNROLL_STRING_IO: > ... > return boot_cpu_has(X86_FEATURE_TDX_GUEST); > > /* attributes applied to TDX host only */ > case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: > case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: > return platform_tdx_enabled(); > > default: > return false; > } > } > > so that we can get rid of #ifdef/endif. Personally I don't quite like this way. To me having separate function for host and guest is more clear and more flexible. And I don't think having #ifdef/endif has any problem. I would like to leave to maintainers.
On Fri, Jun 24, 2022 at 11:21:59PM +1200, Kai Huang wrote: > On Fri, 2022-06-24 at 09:41 +0800, Chao Gao wrote: > > On Wed, Jun 22, 2022 at 11:16:07PM +1200, Kai Huang wrote: > > > -static bool intel_cc_platform_has(enum cc_attr attr) > > > +#ifdef CONFIG_INTEL_TDX_GUEST > > > +static bool intel_tdx_guest_has(enum cc_attr attr) > > > { > > > switch (attr) { > > > case CC_ATTR_GUEST_UNROLL_STRING_IO: > > > @@ -28,6 +31,33 @@ static bool intel_cc_platform_has(enum cc_attr attr) > > > return false; > > > } > > > } > > > +#endif > > > + > > > +#ifdef CONFIG_INTEL_TDX_HOST > > > +static bool intel_tdx_host_has(enum cc_attr attr) > > > +{ > > > + switch (attr) { > > > + case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: > > > + case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: > > > + return true; > > > + default: > > > + return false; > > > + } > > > +} > > > +#endif > > > + > > > +static bool intel_cc_platform_has(enum cc_attr attr) > > > +{ > > > +#ifdef CONFIG_INTEL_TDX_GUEST > > > + if (boot_cpu_has(X86_FEATURE_TDX_GUEST)) > > > + return intel_tdx_guest_has(attr); > > > +#endif > > > +#ifdef CONFIG_INTEL_TDX_HOST > > > + if (platform_tdx_enabled()) > > > + return intel_tdx_host_has(attr); > > > +#endif > > > + return false; > > > +} > > > > how about: > > > > static bool intel_cc_platform_has(enum cc_attr attr) > > { > > switch (attr) { > > /* attributes applied to TDX guest only */ > > case CC_ATTR_GUEST_UNROLL_STRING_IO: > > ... > > return boot_cpu_has(X86_FEATURE_TDX_GUEST); > > > > /* attributes applied to TDX host only */ > > case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: > > case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: > > return platform_tdx_enabled(); > > > > default: > > return false; > > } > > } > > > > so that we can get rid of #ifdef/endif. > > Personally I don't quite like this way. To me having separate function for host > and guest is more clear and more flexible. And I don't think having > #ifdef/endif has any problem. I would like to leave to maintainers. I see below statement, for you reference: "Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c" From Documentation/process/coding-style.rst, 21) Conditional Compilation. > > -- > Thanks, > -Kai > >
On Wed, 2022-06-29 at 16:35 +0800, Yuan Yao wrote: > On Fri, Jun 24, 2022 at 11:21:59PM +1200, Kai Huang wrote: > > On Fri, 2022-06-24 at 09:41 +0800, Chao Gao wrote: > > > On Wed, Jun 22, 2022 at 11:16:07PM +1200, Kai Huang wrote: > > > > -static bool intel_cc_platform_has(enum cc_attr attr) > > > > +#ifdef CONFIG_INTEL_TDX_GUEST > > > > +static bool intel_tdx_guest_has(enum cc_attr attr) > > > > { > > > > switch (attr) { > > > > case CC_ATTR_GUEST_UNROLL_STRING_IO: > > > > @@ -28,6 +31,33 @@ static bool intel_cc_platform_has(enum cc_attr attr) > > > > return false; > > > > } > > > > } > > > > +#endif > > > > + > > > > +#ifdef CONFIG_INTEL_TDX_HOST > > > > +static bool intel_tdx_host_has(enum cc_attr attr) > > > > +{ > > > > + switch (attr) { > > > > + case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: > > > > + case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: > > > > + return true; > > > > + default: > > > > + return false; > > > > + } > > > > +} > > > > +#endif > > > > + > > > > +static bool intel_cc_platform_has(enum cc_attr attr) > > > > +{ > > > > +#ifdef CONFIG_INTEL_TDX_GUEST > > > > + if (boot_cpu_has(X86_FEATURE_TDX_GUEST)) > > > > + return intel_tdx_guest_has(attr); > > > > +#endif > > > > +#ifdef CONFIG_INTEL_TDX_HOST > > > > + if (platform_tdx_enabled()) > > > > + return intel_tdx_host_has(attr); > > > > +#endif > > > > + return false; > > > > +} > > > > > > how about: > > > > > > static bool intel_cc_platform_has(enum cc_attr attr) > > > { > > > switch (attr) { > > > /* attributes applied to TDX guest only */ > > > case CC_ATTR_GUEST_UNROLL_STRING_IO: > > > ... > > > return boot_cpu_has(X86_FEATURE_TDX_GUEST); > > > > > > /* attributes applied to TDX host only */ > > > case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: > > > case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: > > > return platform_tdx_enabled(); > > > > > > default: > > > return false; > > > } > > > } > > > > > > so that we can get rid of #ifdef/endif. > > > > Personally I don't quite like this way. To me having separate function for host > > and guest is more clear and more flexible. And I don't think having > > #ifdef/endif has any problem. I would like to leave to maintainers. > > I see below statement, for you reference: > > "Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c" > From Documentation/process/coding-style.rst, 21) Conditional Compilation. > > > This is perhaps a general rule. If you take a look at existing code, you will immediately find AMD has a #ifdef too: static bool amd_cc_platform_has(enum cc_attr attr) { #ifdef CONFIG_AMD_MEM_ENCRYPT switch (attr) { case CC_ATTR_MEM_ENCRYPT: return sme_me_mask; case CC_ATTR_HOST_MEM_ENCRYPT: return sme_me_mask && !(sev_status & MSR_AMD64_SEV_ENABLED); case CC_ATTR_GUEST_MEM_ENCRYPT: return sev_status & MSR_AMD64_SEV_ENABLED; case CC_ATTR_GUEST_STATE_ENCRYPT: return sev_status & MSR_AMD64_SEV_ES_ENABLED; /* * With SEV, the rep string I/O instructions need to be unrolled * but SEV-ES supports them through the #VC handler. */ case CC_ATTR_GUEST_UNROLL_STRING_IO: return (sev_status & MSR_AMD64_SEV_ENABLED) && !(sev_status & MSR_AMD64_SEV_ES_ENABLED); default: return false; } #else return false; #endif } So I'll leave to maintainers. Anyway as Christoph commented I'll give up introducing new CC attributes, so doesn't matter anymore.
On 6/24/22 04:21, Kai Huang wrote: > Personally I don't quite like this way. To me having separate function for host > and guest is more clear and more flexible. And I don't think having > #ifdef/endif has any problem. I would like to leave to maintainers. It has problems. Let's go through some of them. First, this: > +#ifdef CONFIG_INTEL_TDX_HOST > +static bool intel_tdx_host_has(enum cc_attr attr) > +{ > + switch (attr) { > + case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: > + case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: > + return true; > + default: > + return false; > + } > +} > +#endif What does that #ifdef get us? I suspect you're back to trying to silence compiler warnings with #ifdefs. The compiler *knows* that it's only used in this file. It's also used all of once. If you make it 'static inline', you'll likely get the same code generation, no warnings, and don't need an #ifdef. The other option is to totally lean on the compiler to figure things out. Compile this program, then disassemble it and see what main() does. static void func(void) { printf("I am func()\n"); } void main(int argc, char **argv) { if (0) func(); } Then, do: - if (0) + if (argc) and run it again. What changed in the disassembly? > +static bool intel_cc_platform_has(enum cc_attr attr) > +{ > +#ifdef CONFIG_INTEL_TDX_GUEST > + if (boot_cpu_has(X86_FEATURE_TDX_GUEST)) > + return intel_tdx_guest_has(attr); > +#endif Make this check cpu_feature_enabled(X86_FEATURE_TDX_GUEST). That has an #ifdef built in to it. That gets rid of this #ifdef. You have > +#ifdef CONFIG_INTEL_TDX_HOST > + if (platform_tdx_enabled()) > + return intel_tdx_host_has(attr); > +#endif > + return false; > +} Now, let's turn our attention to platform_tdx_enabled(). Here's its stub and declaration: > +#ifdef CONFIG_INTEL_TDX_HOST > +bool platform_tdx_enabled(void); > +#else /* !CONFIG_INTEL_TDX_HOST */ > +static inline bool platform_tdx_enabled(void) { return false; } > +#endif /* CONFIG_INTEL_TDX_HOST */ It already has an #ifdef CONFIG_INTEL_TDX_HOST, so that #ifdef can just go away. Kai, the reason that we have the rule that Yuan cited: > "Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c" > From Documentation/process/coding-style.rst, 21) Conditional Compilation. is not because there are *ZERO* #ifdefs in .c files. It's because #ifdefs in .c files hurt readability and are usually avoidable. How do you avoid them? Well, you take a moment and look at the code and see how other folks have made it readable. It takes refactoring of code to banish #ifdefs to headers or replace them with compiler constructs so that the compiler can do the work behind the scenes. Kai, could you please take the information I gave you in this message and try to apply it across this series? Heck, can you please take it and use it to review others' code to make sure they don't encounter the same pitfalls?
On Wed, 2022-06-29 at 07:22 -0700, Dave Hansen wrote: > On 6/24/22 04:21, Kai Huang wrote: > > Personally I don't quite like this way. To me having separate function for host > > and guest is more clear and more flexible. And I don't think having > > #ifdef/endif has any problem. I would like to leave to maintainers. > > It has problems. > > Let's go through some of them. First, this: > > > +#ifdef CONFIG_INTEL_TDX_HOST > > +static bool intel_tdx_host_has(enum cc_attr attr) > > +{ > > + switch (attr) { > > + case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: > > + case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: > > + return true; > > + default: > > + return false; > > + } > > +} > > +#endif > > What does that #ifdef get us? I suspect you're back to trying to > silence compiler warnings with #ifdefs. The compiler *knows* that it's > only used in this file. It's also used all of once. If you make it > 'static inline', you'll likely get the same code generation, no > warnings, and don't need an #ifdef. The purpose is not to avoid warning, but to make intel_cc_platform_has(enum cc_attr attr) simple that when neither TDX host and TDX guest code is turned on, it can be simple: static bool intel_cc_platform_has(enum cc_attr attr) { return false; } So I don't need to depend on how internal functions are implemented in the header files and I don't need to guess how does compiler generate code. And also because I personally believe it doesn't hurt readability. > > The other option is to totally lean on the compiler to figure things > out. Compile this program, then disassemble it and see what main() does. > > static void func(void) > { > printf("I am func()\n"); > } > > void main(int argc, char **argv) > { > if (0) > func(); > } > > Then, do: > > - if (0) > + if (argc) > > and run it again. What changed in the disassembly? You mean compile it again? I have to confess I never tried and don't know. I'll try when I got some spare time. Thanks for the info. > > > +static bool intel_cc_platform_has(enum cc_attr attr) > > +{ > > +#ifdef CONFIG_INTEL_TDX_GUEST > > + if (boot_cpu_has(X86_FEATURE_TDX_GUEST)) > > + return intel_tdx_guest_has(attr); > > +#endif > > Make this check cpu_feature_enabled(X86_FEATURE_TDX_GUEST). That has an > #ifdef built in to it. That gets rid of this #ifdef. You have > > > +#ifdef CONFIG_INTEL_TDX_HOST > > + if (platform_tdx_enabled()) > > + return intel_tdx_host_has(attr); > > +#endif > > + return false; > > +} > > Now, let's turn our attention to platform_tdx_enabled(). Here's its > stub and declaration: > > > +#ifdef CONFIG_INTEL_TDX_HOST > > +bool platform_tdx_enabled(void); > > +#else /* !CONFIG_INTEL_TDX_HOST */ > > +static inline bool platform_tdx_enabled(void) { return false; } > > +#endif /* CONFIG_INTEL_TDX_HOST */ > > It already has an #ifdef CONFIG_INTEL_TDX_HOST, so that #ifdef can just > go away. > > Kai, the reason that we have the rule that Yuan cited: > > > "Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c" > > From Documentation/process/coding-style.rst, 21) Conditional Compilation. > > is not because there are *ZERO* #ifdefs in .c files. It's because > #ifdefs in .c files hurt readability and are usually avoidable. How do > you avoid them? Well, you take a moment and look at the code and see > how other folks have made it readable. It takes refactoring of code to > banish #ifdefs to headers or replace them with compiler constructs so > that the compiler can do the work behind the scenes. Yes I understand the purpose of this rule. Thanks for explaining. > > Kai, could you please take the information I gave you in this message > and try to apply it across this series? Heck, can you please take it > and use it to review others' code to make sure they don't encounter the > same pitfalls? Thanks for the tip. Will do. Btw this patch is the only one in this series that has this #ifdef problem, and it will be gone in next version based on feedbacks that I received. But I'll check again.
On 6/29/22 16:02, Kai Huang wrote: > On Wed, 2022-06-29 at 07:22 -0700, Dave Hansen wrote: >> On 6/24/22 04:21, Kai Huang wrote: >> What does that #ifdef get us? I suspect you're back to trying to >> silence compiler warnings with #ifdefs. The compiler *knows* that it's >> only used in this file. It's also used all of once. If you make it >> 'static inline', you'll likely get the same code generation, no >> warnings, and don't need an #ifdef. > > The purpose is not to avoid warning, but to make intel_cc_platform_has(enum > cc_attr attr) simple that when neither TDX host and TDX guest code is turned on, > it can be simple: > > static bool intel_cc_platform_has(enum cc_attr attr) > { > return false; > } > > So I don't need to depend on how internal functions are implemented in the > header files and I don't need to guess how does compiler generate code. I hate to break it to you, but you actually need to know how the compiler works for you to be able to write good code. Ignoring all the great stuff that the compiler does for you makes your code worse. > And also because I personally believe it doesn't hurt readability. Are you saying that you're ignoring long-established kernel coding style conventions because of your personal beliefs? That seem, um, like an approach that's unlikely to help your code get accepted. >> The other option is to totally lean on the compiler to figure things >> out. Compile this program, then disassemble it and see what main() does. >> >> static void func(void) >> { >> printf("I am func()\n"); >> } >> >> void main(int argc, char **argv) >> { >> if (0) >> func(); >> } >> >> Then, do: >> >> - if (0) >> + if (argc) >> >> and run it again. What changed in the disassembly? > > You mean compile it again? I have to confess I never tried and don't know. > I'll try when I got some spare time. Thanks for the info. Yes, compile it again and run it again. But, seriously, it's a quick exercise. I can help make you some spare time if you wish. Just let me know.
On Thu, 2022-06-30 at 08:44 -0700, Dave Hansen wrote: > On 6/29/22 16:02, Kai Huang wrote: > > On Wed, 2022-06-29 at 07:22 -0700, Dave Hansen wrote: > > > On 6/24/22 04:21, Kai Huang wrote: > > > What does that #ifdef get us? I suspect you're back to trying to > > > silence compiler warnings with #ifdefs. The compiler *knows* that it's > > > only used in this file. It's also used all of once. If you make it > > > 'static inline', you'll likely get the same code generation, no > > > warnings, and don't need an #ifdef. > > > > The purpose is not to avoid warning, but to make intel_cc_platform_has(enum > > cc_attr attr) simple that when neither TDX host and TDX guest code is turned on, > > it can be simple: > > > > static bool intel_cc_platform_has(enum cc_attr attr) > > { > > return false; > > } > > > > So I don't need to depend on how internal functions are implemented in the > > header files and I don't need to guess how does compiler generate code. > > I hate to break it to you, but you actually need to know how the > compiler works for you to be able to write good code. Ignoring all the > great stuff that the compiler does for you makes your code worse. Agreed. > > > And also because I personally believe it doesn't hurt readability. > > Are you saying that you're ignoring long-established kernel coding style > conventions because of your personal beliefs? That seem, um, like an > approach that's unlikely to help your code get accepted. Agreed. Will keep this in mind. Thanks. > > > > The other option is to totally lean on the compiler to figure things > > > out. Compile this program, then disassemble it and see what main() does. > > > > > > static void func(void) > > > { > > > printf("I am func()\n"); > > > } > > > > > > void main(int argc, char **argv) > > > { > > > if (0) > > > func(); > > > } > > > > > > Then, do: > > > > > > - if (0) > > > + if (argc) > > > > > > and run it again. What changed in the disassembly? > > > > You mean compile it again? I have to confess I never tried and don't know. > > I'll try when I got some spare time. Thanks for the info. > > Yes, compile it again and run it again. > > But, seriously, it's a quick exercise. I can help make you some spare > time if you wish. Just let me know. So I tried. Took me less than 5 mins:) The if (0) func(); never generates the code to actually call the func(): 0000000000401137 <main>: 401137: 55 push %rbp 401138: 48 89 e5 mov %rsp,%rbp 40113b: 89 7d fc mov %edi,-0x4(%rbp) 40113e: 48 89 75 f0 mov %rsi,-0x10(%rbp) 401142: 90 nop 401143: 5d pop %rbp 401144: c3 ret While if (argc) func(); generates the code to check argc and call func(): 0000000000401137 <main>: 401137: 55 push %rbp 401138: 48 89 e5 mov %rsp,%rbp 40113b: 48 83 ec 10 sub $0x10,%rsp 40113f: 89 7d fc mov %edi,-0x4(%rbp) 401142: 48 89 75 f0 mov %rsi,-0x10(%rbp) 401146: 83 7d fc 00 cmpl $0x0,-0x4(%rbp) 40114a: 74 05 je 401151 <main+0x1a> 40114c: e8 d5 ff ff ff call 401126 <func> 401151: 90 nop 401152: c9 leave 401153: c3 ret This is kinda no surprise. Were you trying to make point that if (false) func(); doesn't generate any additional code? I get your point now. Thanks :)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 23f21aa3a5c4..efa830853e98 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1973,6 +1973,7 @@ config INTEL_TDX_HOST depends on CPU_SUP_INTEL depends on X86_64 depends on KVM_INTEL + select ARCH_HAS_CC_PLATFORM help Intel Trust Domain Extensions (TDX) protects guest VMs from malicious host and certain physical attacks. This option enables necessary TDX diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c index 1bde1af75296..e4c9e34c452f 100644 --- a/arch/x86/coco/core.c +++ b/arch/x86/coco/core.c @@ -12,11 +12,14 @@ #include <asm/coco.h> #include <asm/processor.h> +#include <asm/cpufeature.h> +#include <asm/tdx.h> static enum cc_vendor vendor __ro_after_init; static u64 cc_mask __ro_after_init; -static bool intel_cc_platform_has(enum cc_attr attr) +#ifdef CONFIG_INTEL_TDX_GUEST +static bool intel_tdx_guest_has(enum cc_attr attr) { switch (attr) { case CC_ATTR_GUEST_UNROLL_STRING_IO: @@ -28,6 +31,33 @@ static bool intel_cc_platform_has(enum cc_attr attr) return false; } } +#endif + +#ifdef CONFIG_INTEL_TDX_HOST +static bool intel_tdx_host_has(enum cc_attr attr) +{ + switch (attr) { + case CC_ATTR_ACPI_CPU_HOTPLUG_DISABLED: + case CC_ATTR_ACPI_MEMORY_HOTPLUG_DISABLED: + return true; + default: + return false; + } +} +#endif + +static bool intel_cc_platform_has(enum cc_attr attr) +{ +#ifdef CONFIG_INTEL_TDX_GUEST + if (boot_cpu_has(X86_FEATURE_TDX_GUEST)) + return intel_tdx_guest_has(attr); +#endif +#ifdef CONFIG_INTEL_TDX_HOST + if (platform_tdx_enabled()) + return intel_tdx_host_has(attr); +#endif + return false; +} /* * SME and SEV are very similar but they are not the same, so there are diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 8275007702e6..eb3294bf1b0a 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -15,6 +15,7 @@ #include <asm/msr-index.h> #include <asm/msr.h> #include <asm/tdx.h> +#include <asm/coco.h> #include "tdx.h" static u32 tdx_keyid_start __ro_after_init; @@ -92,6 +93,9 @@ static int __init tdx_early_detect(void) if (ret) return ret; + /* Set TDX enabled platform as confidential computing platform */ + cc_set_vendor(CC_VENDOR_INTEL); + pr_info("TDX enabled by BIOS.\n"); return 0; }
Intel Trust Domain Extensions (TDX) protects guest VMs from malicious host and certain physical attacks. To guarantee the security, TDX imposes additional requirements on both CPU and memory. TDX doesn't work with ACPI CPU hotplug. During platform boot, MCHECK verifies all logical CPUs on all packages are TDX compatible. Any hot-added CPU at runtime is not verified thus cannot support TDX. And TDX requires all boot-time verified CPUs being present during machine's runtime, so TDX doesn't support ACPI CPU hot-removal either. TDX doesn't work with ACPI memory hotplug either. TDX also provides increased levels of memory confidentiality and integrity. During platform boot, MCHECK also verifies all TDX-capable memory regions are physically present and meet TDX's security requirements. Any hot-added memory is not verified thus cannot work with TDX. TDX also assumes all TDX-capable memory regions are present during machine's runtime thus it doesn't support ACPI memory removal either. Select ARCH_HAS_CC_PLATFORM when CONFIG_INTEL_TDX_HOST is on. Set CC vendor to CC_VENDOR_INTEL if TDX is enabled by BIOS, and report ACPI CPU hotplug and ACPI memory hotplug attributes as disabled to prevent them. Note TDX does allow CPU to go offline and then to be brought up again, so software CPU hotplug attribute is not reported. Signed-off-by: Kai Huang <kai.huang@intel.com> --- arch/x86/Kconfig | 1 + arch/x86/coco/core.c | 32 +++++++++++++++++++++++++++++++- arch/x86/virt/vmx/tdx/tdx.c | 4 ++++ 3 files changed, 36 insertions(+), 1 deletion(-)