Re: [PATCH v3 1/1] x86/mce/amd: Guard SMCA DESTAT access on non-SMCA machines

[Borislav Petkov]

On Tue, Mar 17, 2026 at 10:52:50PM +0100, William Roche wrote:
> The physical address of an uncorrected memory error (if/when it can be
> identified) can give a chance to a kernel reaction depending on the state
> (and type) of the impacted memory -- as implemented in mm/memory-failure.c
> with error_states[], me_pagecache_clean() or try_memory_failure()...
> 
> The Kernel can try to "deal" with the error. The process case (with its
> SIGBUS) is probably the most common one, but a few kernel memory pages
> impacted by a memory error could be isolated (poisoned) without requiring a
> kernel crash. Free memory pages or clean page cache pages could be an
> example of that, they are poisoned and should not be used by the system
> after that. The kernel can also return EIO error on poisoned page cache
> failed access attempt, etc...
> 
> These mechanisms are implemented for the bare-metal running kernel, but what
> is really interesting when relaying the error to a VM is that its kernel
> can, in some cases, also benefit from these mechanisms. And having a chance
> (even small) to avoid a VM crash is a significant gain for virtualized
> workload.
> 
> Just giving my point of view on why we care about VM relayed memory errors
> :)

Ah, you want to be able to handle an error belonging to a guest, regardless of
which part it hits. As in, the guest memory hit could be pagecache, free
memory, etc... anything that would prevent the guest from dying unnecessary
death.

Ack, makes sense.

Thx.

-- 
Regards/Gruss,
    Boris.

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