All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Kai" <kai.huang@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>,
	"Hunter, Adrian" <adrian.hunter@intel.com>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"Annapurve, Vishal" <vannapurve@google.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Li, Xiaoyao" <xiaoyao.li@intel.com>,
	"Zhao, Yan Y" <yan.y.zhao@intel.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"tony.lindgren@linux.intel.com" <tony.lindgren@linux.intel.com>,
	"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
	"Chatre, Reinette" <reinette.chatre@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"Yamahata, Isaku" <isaku.yamahata@intel.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"seanjc@google.com" <seanjc@google.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	"bp@alien8.de" <bp@alien8.de>, "Gao, Chao" <chao.gao@intel.com>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 1/2] x86/mce: Fix missing address mask in recovery for errors in TDX/SEAM non-root mode
Date: Wed, 30 Jul 2025 11:57:08 +0000	[thread overview]
Message-ID: <287caf7fda25b8ac27211d2e50fa1077e0bf0bf6.camel@intel.com> (raw)
In-Reply-To: <807ff02d-7af0-419d-8d14-a4d6c5d5420d@intel.com>

On Wed, 2025-07-30 at 13:54 +0300, Adrian Hunter wrote:
> But there are also additional places where it seems like MCI_ADDR_PHYSADDR
> is missing:
> 
> 	tdx_dump_mce_info()
> 		paddr_is_tdx_private()
> 			__seamcall_ret(TDH_PHYMEM_PAGE_RDMD, &args)
> 				TDH_PHYMEM_PAGE_RDMD expects KeyID bits to be zero

This is only called in mce_panic() path, which basically means the #MC is
fatal, e.g., happens in kernel context.

The intention of this is to catch any #MC due to kernel bug (i.e.,
software issue, but not hardware error) which does partial write to TDX
private memory and read at a later time, and report a more precise
information to the user to point out this could be due to "possible kernel
bug".  See changelog of 70060463cb2b ("x86/mce: Differentiate real
hardware #MCs from TDX erratum ones").

In other words, for this case the address reported via MCI_ADDR_PHYSADDR
should not contain any KeyID bits since the kernel always uses keyID 0 to
read.

I believe the KeyID bits will only be appended to the physical address
reported in MCI_ADDR_PHYSADDR when the #MC was triggered from TDX guest,
i.e., when the CPU was accessing memory using TDX KeyID.  Such #MC is not
fatal and won't call into mce_panic().

That being said, for tdx_dump_mce_info(), while explicitly masking out
keyID bits in MCI_ADDR_PHYSADDR obviously doesn't hurt (or arguably better
in some way), it is not necessary AFAICT.

  reply	other threads:[~2025-07-30 11:57 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18 12:08 [PATCH 0/2] Fixes for recovery for machine check in TDX/SEAM non-root mode Adrian Hunter
2025-06-18 12:08 ` [PATCH 1/2] x86/mce: Fix missing address mask in recovery for errors " Adrian Hunter
2025-06-18 12:36   ` Xiaoyao Li
2025-06-18 14:55   ` Dave Hansen
2025-06-19 11:57     ` Adrian Hunter
2025-06-27 15:23       ` Adrian Hunter
2025-06-27 15:25         ` Dave Hansen
2025-06-27 16:24           ` Luck, Tony
2025-06-27 16:33             ` Dave Hansen
2025-07-30 10:54               ` Adrian Hunter
2025-07-30 11:57                 ` Huang, Kai [this message]
2025-07-30 14:20                 ` Vishal Annapurve
2025-06-27 16:28         ` Luck, Tony
2025-06-18 23:20   ` Huang, Kai
2025-06-18 23:39     ` Luck, Tony
2025-06-18 23:46       ` Luck, Tony
2025-06-18 23:57         ` Huang, Kai
2025-06-18 23:53       ` Huang, Kai
2025-06-18 12:08 ` [PATCH 2/2] KVM: TDX: Do not clear poisoned pages Adrian Hunter
2025-06-18 12:39   ` Xiaoyao Li
2025-06-18 14:58   ` Dave Hansen
2025-06-25 14:33     ` Vishal Annapurve
2025-06-25 16:25       ` Adrian Hunter
2025-06-25 16:31         ` Dave Hansen
2025-06-25 16:42           ` Adrian Hunter
2025-06-25 16:57             ` Dave Hansen
2025-06-25 16:42         ` Edgecombe, Rick P
2025-06-25 22:32         ` Huang, Kai
2025-06-25 22:38           ` Dave Hansen
2025-06-26  1:19             ` Huang, Kai
2025-06-26 15:31               ` Luck, Tony
2025-06-26 22:20                 ` Huang, Kai
2025-06-26 22:33                   ` Dave Hansen
2025-06-27  0:56                     ` Huang, Kai
2025-06-18 23:09   ` Huang, Kai

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=287caf7fda25b8ac27211d2e50fa1077e0bf0bf6.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=adrian.hunter@intel.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=chao.gao@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=reinette.chatre@intel.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.lindgren@linux.intel.com \
    --cc=tony.luck@intel.com \
    --cc=vannapurve@google.com \
    --cc=x86@kernel.org \
    --cc=xiaoyao.li@intel.com \
    --cc=yan.y.zhao@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.