public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kai Huang <kai.huang@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Martin Fernandez <martin.fernandez@eclypsium.com>,
	linux-kernel@vger.kernel.org, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, mingo@redhat.com,
	tglx@linutronix.de, kirill.shutemov@linux.intel.com,
	daniel.gutson@eclypsium.com, hughsient@gmail.com,
	alex.bazhaniuk@eclypsium.com
Subject: Re: [PATCH v2] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is disabled by BIOS
Date: Tue, 12 Jul 2022 13:39:06 +1200	[thread overview]
Message-ID: <07ff13d590cf290a14232fb113ff4183a6fa352d.camel@intel.com> (raw)
In-Reply-To: <YszFkTZ7RtXS1rd7@google.com>


> 
> > This patch basically tries to fix the issue that TME flag isn't cleared when TME
> > is disabled by BIOS.  And fir this purpose, the code change in this patch looks
> > reasonable to me.  Unless I am mistaken, detect_tme() will be called for all
> > cpus if TME is supported in CPUID but isn't enabled by BIOS (either LOCKED or
> > ENABLED bit isn't set).
> 
> But this patch doesn't handle the bypass bit, which _does_ effectively disable
> TME when set.  E.g. the MKTME spec says:
> 
>  Software must inspect the Hardware Encryption Enable (bit 1) and TME Encryption
>  Bypass Enable (bit 31) to determine if TME encryption is enabled.

Yeah so my original reply said:

"But perhaps it's arguable whether we can also clear TME flag in this case."

And I only gave my Acked-by.

It completely depends on the purpose of this patch, or what does this patch
claim to do.  If it only claims to clear TME bit if BIOS doesn't enable it, then
looks fine to me.  If it wants to achieve "clear TME feature flag if encryption
isn't active", then yes you are right.  

But as I said perhaps "whether we should clear TME flag when bypass is enabled"
is arguable.  After all, what does TME flag in /proc/cpuinfo imply?

  reply	other threads:[~2022-07-12  1:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-04 14:22 [PATCH v2] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is disabled by BIOS Martin Fernandez
2022-07-05 10:15 ` Kai Huang
2022-07-05 13:21   ` Martin Fernandez
2022-07-11 17:08     ` Sean Christopherson
2022-07-12  0:12       ` Kai Huang
2022-07-12  0:51         ` Sean Christopherson
2022-07-12  1:39           ` Kai Huang [this message]
2022-07-12 12:59             ` Martin Fernandez
2022-07-12 19:14               ` Sean Christopherson

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=07ff13d590cf290a14232fb113ff4183a6fa352d.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=alex.bazhaniuk@eclypsium.com \
    --cc=bp@alien8.de \
    --cc=daniel.gutson@eclypsium.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hughsient@gmail.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.fernandez@eclypsium.com \
    --cc=mingo@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --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