Re: Xens handling of MCE

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Thu, Aug 31, 2023 at 07:52:05PM +0000, Development wrote:
> 
>     However, in 2009-02, "cegger" wrote MCA/MCE_in_Xen, a proposal for having 
> xen start checking the information
>     Xen started accessing the EDAC information (now called "MCE") at some 
> point after that, which blocks the linux kernel in dom0 from accessing it.
>     (I also found what appears to be related sides from a presentation from 
> 2012 at: 
> https://lkml.iu.edu/hypermail/linux/kernel/1206.3/01304/xen_vMCE_design_%28v0_2%29.pdf
>  )
> 

I hadn't seen that before.  Clearly shows someone who had no idea what
they were doing designed it.  The author was thinking "virtualize 
everything!", whereas MCE is a perfect situation for paravirtualization.
Let Dom0 process MCE events (which allows use of Linux's more up to date
MCE drivers), then let Dom0 notify Xen if action is needed (a page was
corrupted, tell the effected domain).

There was a recent proposal to simply import Linux's rather more recent
MCE/EDAC source.  This hasn't happened yet.  For people using Xen this
has been a very concerning issue for some time.

This seems a combination of not enough people using Xen not yet having
gotten quite noisy enough (I think the threshold is being approached),
plus the people with the right development skills being out of touch.

Commit 767f4b620edadac579c9b8b6660761d4285fa6f9 to the Linux kernel yet
again shows someone *REALLY* out of touch!


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445