Re: Thoughts on current Xen EDAC/MCE situation

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.01.2024 23:52, Elliott Mitchell wrote:
> On Tue, Jan 23, 2024 at 11:44:03AM +0100, Jan Beulich wrote:
>> On 22.01.2024 21:53, Elliott Mitchell wrote:
>>
>>> I find the present handling of MCE in Xen an odd choice.  Having Xen do
>>> most of the handling of MCE events is a behavior matching a traditional
>>> stand-alone hypervisor.  Yet Xen was originally pushing any task not
>>> requiring hypervisor action onto Domain 0.
>>
>> Not exactly. Xen in particular deals with all of CPU and all of memory.
>> Dom0 may be unaware of the full amount of CPUs in the system, nor the
>> full memory map (without resorting to interfaces specifically making
>> that information available, but not to be used for Dom0 kernel's own
>> acting as a kernel).
> 
> Why would this be an issue?

Well, counter question: For all of ...

> I would expect the handling to be roughly:  NMI -> Xen; Xen schedules a
> Dom0 vCPU which is eligible to run on the pCPU onto the pCPU; Dom0
> examines registers/MSRs, Dom0 then issues a hypercall to Xen telling
> Xen how to resolve the issue (no action, fix memory contents, kill page).
> 
> Ideally there would be an idle Dom0 vCPU, but interrupting a busy vCPU
> would be viable.  It would even be reasonable to ignore affinity and
> grab any Dom0 vCPU.
> 
> Dom0 has 2 purposes for the address.  First, to pass it back to Xen.
> Second, to report it to a system administrator so they could restart the
> system with that address marked as bad.  Dom0 wouldn't care whether the
> address was directly accessible to it or not.
> 
> The proposed hypercall should report back what was effected by a UE
> event.  A given site might have a policy that if $some_domain is hit by a
> UE, everything is restarted.  Meanwhile Dom0 or Xen being the winner
> could deserve urgent action.

... this, did you first look at code and figure how what you suggest
could be seamlessly integrated? Part of your suggestion (if I got it
right) is, after all, to make maintenance on the Dom0 kernel side easy.
I expect such adjustments being not overly intrusive would also be an
acceptance criteria by the maintainers.

Second - since you specifically talk about UE: The more code is involved
in handling, the higher the chance of the #MC ending up fatal to the
system.

Third, as to Dom0's purposes of having the address: If all it is to use
it for is to pass it back to Xen, paths in the respective drivers will
necessarily be entirely different for the Xen vs the native cases.

Jan