All of lore.kernel.org
 help / color / mirror / Atom feed
From: "kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>
To: "Huang, Kai" <kai.huang@intel.com>
Cc: "mingo@kernel.org" <mingo@kernel.org>,
	"Li, Xin3" <xin3.li@intel.com>,
	"Compostella, Jeremy" <jeremy.compostella@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>, "bp@alien8.de" <bp@alien8.de>
Subject: Re: [PATCH v3 1/2] x86/cpu/intel: Fix MTRR verification for TME enabled platforms
Date: Tue, 3 Oct 2023 01:47:52 +0300	[thread overview]
Message-ID: <20231002224752.33qa2lq7q2w4nqws@box> (raw)
In-Reply-To: <00392c722e65c8d0da40384eecf8955be4875969.camel@intel.com>

On Fri, Sep 29, 2023 at 09:14:00AM +0000, Huang, Kai wrote:
> On Thu, 2023-09-28 at 15:30 -0700, Compostella, Jeremy wrote:
> > On TME enabled platform, BIOS publishes MTRR taking into account Total
> > Memory Encryption (TME) reserved bits.
> > 
> > generic_get_mtrr() performs a sanity check of the MTRRs relying on the
> > `phys_hi_rsvd' variable which is set using the cpuinfo_x86 structure
> > `x86_phys_bits' field.  But at the time the generic_get_mtrr()
> > function is ran the `x86_phys_bits' has not been updated by
> > detect_tme() when TME is enabled.
> > 
> > Since the x86_phys_bits does not reflect yet the real maximal physical
> > address size yet generic_get_mtrr() complains by logging the following
> > messages.
> > 
> >     mtrr: your BIOS has configured an incorrect mask, fixing it.
> >     mtrr: your BIOS has configured an incorrect mask, fixing it.
> >     [...]
> > 
> > In such a situation, generic_get_mtrr() returns an incorrect size but
> > no side effect were observed during our testing.
> > 
> > For `x86_phys_bits' to be updated before generic_get_mtrr() runs,
> > move the detect_tme() call from init_intel() to early_init_intel().
> 
> Hi,
> 
> This move looks good to me, but +Kirill who is the author of detect_tme() for
> further comments.
> 
> Also I am not sure whether it's worth to consider to move this to
> get_cpu_address_sizes(), which calculates the virtual/physical address sizes. 
> Thus it seems anything that can impact physical address size could be put there.

Actually, I am not sure how this patch works. AFAICS after the patch we
have the following callchain:

early_identify_cpu()
  this_cpu->c_early_init() (which is early_init_init())
    detect_tme()
      c->x86_phys_bits -= keyid_bits;
  get_cpu_address_sizes(c);
    c->x86_phys_bits = eax & 0xff;

Looks like get_cpu_address_sizes() would override what detect_tme() does.

I guess we reach the same detect_tme() again via c->c_init() (aka
init_intel()) codepath and get the value right again.

But it seems accidental.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

  reply	other threads:[~2023-10-02 22:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28 22:30 [PATCH v3 1/2] x86/cpu/intel: Fix MTRR verification for TME enabled platforms Compostella, Jeremy
2023-09-29  9:14 ` Huang, Kai
2023-10-02 22:47   ` kirill.shutemov [this message]
2023-10-03  2:06     ` Huang, Kai
2023-10-03  7:06       ` kirill.shutemov
2023-10-13 23:03         ` Compostella, Jeremy
2023-10-14 21:01           ` kirill.shutemov
2023-10-16 16:14             ` Compostella, Jeremy
2023-10-16 16:26               ` kirill.shutemov
2023-10-16 17:00                 ` Compostella, Jeremy
2023-10-17 11:39                   ` kirill.shutemov

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=20231002224752.33qa2lq7q2w4nqws@box \
    --to=kirill.shutemov@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=jeremy.compostella@intel.com \
    --cc=kai.huang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=x86@kernel.org \
    --cc=xin3.li@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.