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 <[email protected]>
---
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(-)
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;
}
--
2.36.1
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.
--
Thanks,
-Kai
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.
--
Thanks,
-Kai
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.
--
Thanks,
-Kai
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 :)