All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yazen Ghannam <yazen.ghannam@amd.com>
To: William Roche <william.roche@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>,
	bp@alien8.de, Thomas Gleixner <tglx@linutronix.de>,
	mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org,
	hpa@zytor.com, "Allen, John" <John.Allen@amd.com>,
	linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jane Chu <jane.chu@oracle.com>
Subject: Re: [RFC] AMD VM crashing on deferred memory error injection
Date: Wed, 11 Feb 2026 11:34:38 -0500	[thread overview]
Message-ID: <20260211163438.GA1637@yaz-khff2.amd.com> (raw)
In-Reply-To: <6f87d29b-c30a-47f8-a519-0e1fba36f1a7@oracle.com>

On Wed, Feb 11, 2026 at 02:42:07AM +0100, William Roche wrote:
> On 2/9/26 22:18, Yazen Ghannam wrote:
> > On Mon, Feb 09, 2026 at 04:08:19PM -0500, Yazen Ghannam wrote:
> > > On Mon, Feb 09, 2026 at 05:36:32PM +0100, William Roche wrote:
> > 
> > [...]
> > 
> > > > According to me, this small kernel fix relies too much on a Qemu AMD
> > > > specific implementation detail.
> > > > 
> > > > Would you have a more appropriate fix to suggest please ?
> > > > 
> > > > Thanks in advance for your feedback.
> > > > William.
> > > 
> > > Thanks William for the report and details.
> > > 
> > > Clearing "STATUS" registers is a normal part of MCA handling.
> > > 
> > > We seem to allow clearing the regular "MCi_STATUS" register. I assume
> > > this gets trapped/ignored by the hypervisor.
> > > 
> > > I expect we need to do the same behavior for the "MCA_DESTAT" register.
> > > 
> > > I'll do some research here, but please do share any pointers you may
> > > have.
> 
> Yazen, I'm simply trying to find an answer in the AMD64 Architecture
> Programmer's Manual, Volume 2: System Programming, 24593
> 
> This documents indicates (In chapter 9.3.3.4 MCA Deferred Error Status
> Register) that:
> "When the deferred error has been processed by the deferred error handler,
> MCA_DESTAT should be
> cleared. If MCA_STATUS also contains a deferred error, MCA_STATUS should be
> cleared."
> 
> So I would imagine that allowing the reset of MCA_DESTAT the same way as
> MCA_STATUS should be what the platform has to allow (or ignore).
> 

Yes, that's what I gathered too.

> > 
> > Sorry for the rapid reply, but I think this is where we need an update.
> > 
> > Linux:
> > arch/x86/kvm/x86.c : set_msr_mce()
> > 
> > Please note the comment:
> > "All CPUs allow writing 0 to MCi_STATUS MSRs to clear the MSR."
> > 
> > We should include the MCA_DESTAT register range here.
> > 
> > What do you think?
> 
> But before trying to update the set_msr_mce() function, I don't think
> that KVM keeps track of an MSR_AMD64_SMCA_MCx_DESTAT set of registers.
> I can see mce_banks (for ctl, status, addr and misc) and mci_ctl2_banks
> locations in struct kvm_vcpu_arch, but I don't see a location for SMCA
> banks like MCA_DESTAT MSRs.
> 
> So if we make kvm ignore this update instead of raising a #GP error,
> would it be a valid solution ?
> 

Yes, I think so. And the details depend on how much of the platform
needs to be emulated.

Some ideas in increasing order of complexity:

1) Ignore this register write.

2) Do a basic validity check.
   Allow "write 0 to MCA_DESTAT" and #GP for any other value.
   Don't need to save MCA_DESTAT values.

3) Replicate the full platform behavior akin to MCi_STATUS.
   Would need to save MCA_DESTAT values and do a "HWCR" bit check.

I really don't think we want #3. This would useful for "register-based
error injection/simulation"r. But that use case wouldn't do much with the
MCA_DESTAT register without all the related Deferred error interrupt
infrastructure.

So I say the choice is between #1 and #2.

Thanks,
Yazen

  reply	other threads:[~2026-02-11 16:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-09 16:36 [RFC] AMD VM crashing on deferred memory error injection William Roche
2026-02-09 17:36 ` Borislav Petkov
2026-02-09 17:38   ` Luck, Tony
2026-02-09 17:53     ` Borislav Petkov
2026-02-09 21:08 ` Yazen Ghannam
2026-02-09 21:18   ` Yazen Ghannam
2026-02-11  1:42     ` William Roche
2026-02-11 16:34       ` Yazen Ghannam [this message]
2026-02-12 15:36         ` William Roche
2026-02-12 19:30           ` Yazen Ghannam
2026-02-13 16:55             ` William Roche

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=20260211163438.GA1637@yaz-khff2.amd.com \
    --to=yazen.ghannam@amd.com \
    --cc=John.Allen@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jane.chu@oracle.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=william.roche@oracle.com \
    --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 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.