Log the L1TF mitigation like other mitigatioons. This one is is the
only one that doesn't get logged.

Signed-off-by: Khalid Ali <khaliidcaliy@gmail.com>
---
 arch/x86/kernel/cpu/bugs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 7f94e6a5497d..38cb2a1b2849 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -2803,6 +2803,7 @@ static void __init l1tf_apply_mitigation(void)
 		return;
 	}
 
+	pr_info("Mitigation: PTE inversion\n");
 	setup_force_cpu_cap(X86_FEATURE_L1TF_PTEINV);
 }
 
-- 
2.49.0

On Mon, Jun 02, 2025 at 07:37:06AM +0000, Khalid Ali wrote:
> Log the L1TF mitigation like other mitigatioons. This one is is the
> only one that doesn't get logged.
> 
> Signed-off-by: Khalid Ali <khaliidcaliy@gmail.com>
> ---
>  arch/x86/kernel/cpu/bugs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 7f94e6a5497d..38cb2a1b2849 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -2803,6 +2803,7 @@ static void __init l1tf_apply_mitigation(void)
>  		return;
>  	}
>  
> +	pr_info("Mitigation: PTE inversion\n");
>  	setup_force_cpu_cap(X86_FEATURE_L1TF_PTEINV);
>  }

Pawan, what's the story here?

There's this stuff further down in that file:

| #define L1TF_DEFAULT_MSG "Mitigation: PTE Inversion"
|         
| #if IS_ENABLED(CONFIG_KVM_INTEL)
| static const char * const l1tf_vmx_states[] = {

which comes from 2018:

72c6d2db64fa ("x86/litf: Introduce vmx status variable")

I guess it is about time we made this mitigation also follow the common
pattern with the mitigation strings and issuing them at the right time?

:-)

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Mon, Jun 02, 2025 at 11:09:42AM +0200, Borislav Petkov wrote:
> On Mon, Jun 02, 2025 at 07:37:06AM +0000, Khalid Ali wrote:
> > Log the L1TF mitigation like other mitigatioons. This one is is the
> > only one that doesn't get logged.
> > 
> > Signed-off-by: Khalid Ali <khaliidcaliy@gmail.com>
> > ---
> >  arch/x86/kernel/cpu/bugs.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > index 7f94e6a5497d..38cb2a1b2849 100644
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
> > @@ -2803,6 +2803,7 @@ static void __init l1tf_apply_mitigation(void)
> >  		return;
> >  	}
> >  
> > +	pr_info("Mitigation: PTE inversion\n");
> >  	setup_force_cpu_cap(X86_FEATURE_L1TF_PTEINV);
> >  }
> 
> Pawan, what's the story here?
> 
> There's this stuff further down in that file:
> 
> | #define L1TF_DEFAULT_MSG "Mitigation: PTE Inversion"
> |         
> | #if IS_ENABLED(CONFIG_KVM_INTEL)
> | static const char * const l1tf_vmx_states[] = {
> 
> which comes from 2018:
> 
> 72c6d2db64fa ("x86/litf: Introduce vmx status variable")

I don't know the back story, but L1TF does have too many KVM specific
modes. Probably thats why it is separate from the main mitigation. Also the
KVM part can be compiled out for CONFIG_KVM=n (although it is not a common
practice).

> I guess it is about time we made this mitigation also follow the common
> pattern with the mitigation strings and issuing them at the right time?

I will try to combine the KVM part with the main mitigation.

> > Log the L1TF mitigation like other mitigatioons. This one is is the
> > only one that doesn't get logged.
> >
> > Signed-off-by: Khalid Ali <khaliidcaliy@gmail.com>
> > ---
> > arch/x86/kernel/cpu/bugs.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > index 7f94e6a5497d..38cb2a1b2849 100644
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
> > @@ -2803,6 +2803,7 @@ static void __init l1tf_apply_mitigation(void)
> > 		return;
> > 	}
> >  
> > +	pr_info("Mitigation: PTE inversion\n");
> >  	setup_force_cpu_cap(X86_FEATURE_L1TF_PTEINV);
> >  }

> Pawan, what's the story here?
>
> There's this stuff further down in that file:
>
> | #define L1TF_DEFAULT_MSG "Mitigation: PTE Inversion"
> |         
> | #if IS_ENABLED(CONFIG_KVM_INTEL)
> | static const char * const l1tf_vmx_states[] = {
>
> which comes from 2018:
> 
> 72c6d2db64fa ("x86/litf: Introduce vmx status variable")
> 
> I guess it is about time we made this mitigation also follow the common
> pattern with the mitigation strings and issuing them at the right time?
>
> :-)
>
> Thx.

Exactly, this mitigation is the only one doesn't have string, 
so i thought it is odd. Not only this but we need to make all 
mitigations consistent.

I think the commit you mentioned (72c6d2db64fa ("x86/litf: Introduce vmx status variable"))
and mine have different context (one related to vmx and other common options), and i couldn't
find any string to express since enum values are basically different. enum l1tf_mitigations 
seems more general like "off" or "on" doesn't dictate any special mitigation option. So the 
simplest way maybe is to print the string like "PTE inversion".

Maybe we should move the macro at top of the function so it can print it. This is the only 
information we can print about L1TF mitigation.

Regards 
Khalid Ali