Pkg xen devel - May 2017 - Bug#810964: [Xen-devel] [BUG] EDAC infomation partially missing

I haven't yet done as much experimentation as Andreas Pflug has, but I
can confirm I'm also running into this bug with Xen 4.4.1.

I've only tried Linux kernel 3.16.43, but as Dom0:

EDAC MC: Ver: 3.0.0
AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: NB MCE bank disabled, set MSR 0x0000017b[4] on node 0 to enable.
EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load.
AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: NB MCE bank disabled, set MSR 0x0000017b[4] on node 0 to enable.
EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load.

Whereas directly booting:

EDAC MC: Ver: 3.0.0
AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 0).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0:     0MB 1:     0MB
EDAC amd64: MC: 2:     0MB 3:     0MB
EDAC amd64: MC: 4:     0MB 5:     0MB
EDAC amd64: MC: 6:     0MB 7:     0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0:  4096MB 1:  4096MB
EDAC amd64: MC: 2:     0MB 3:     0MB
EDAC amd64: MC: 4:     0MB 5:     0MB
EDAC amd64: MC: 6:     0MB 7:     0MB
EDAC amd64: using x4 syndromes.
EDAC amd64: MCT channel count: 2
EDAC amd64: CS0: Unbuffered DDR3 RAM
EDAC amd64: CS1: Unbuffered DDR3 RAM
EDAC MC0: Giving out device to module amd64_edac controller F10h: DEV
0000:00:18.2 (INTERRUPT)
EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI
controller: DEV 0000:00:18.2 (POLLED)

I have not tried force-enabling ECC checking.  Since I place high value
on my data, I rate this as a rather important bug.


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

>>> On 14.05.17 at 00:36, <ehem+debian at m5p.com> wrote:
> I haven't yet done as much experimentation as Andreas Pflug has, but I
> can confirm I'm also running into this bug with Xen 4.4.1.
> 
> I've only tried Linux kernel 3.16.43, but as Dom0:
> 
> EDAC MC: Ver: 3.0.0
> AMD64 EDAC driver v3.4.0
> EDAC amd64: DRAM ECC enabled.
> EDAC amd64: NB MCE bank disabled, set MSR 0x0000017b[4] on node 0 to
enable.
> EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not 
> load.
> AMD64 EDAC driver v3.4.0
> EDAC amd64: DRAM ECC enabled.
> EDAC amd64: NB MCE bank disabled, set MSR 0x0000017b[4] on node 0 to
enable.
> EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not 
> load.
Afaict the driver as is simply can't work in a Xen Dom0; it needs
enabling (read: para-virtualizing). I'm actually glad to see it doesn't
load (the worse alternative would be for it to load and then do the
wrong thing or give you a false sense of safety of your data).

Jan

On Mon, May 15, 2017 at 02:02:53AM -0600, Jan Beulich
wrote:
> >>> On 14.05.17 at 00:36, <ehem+debian at m5p.com> wrote:
> > I haven't yet done as much experimentation as Andreas Pflug has,
but I
> > can confirm I'm also running into this bug with Xen 4.4.1.
> > 
> > I've only tried Linux kernel 3.16.43, but as Dom0:
> > 
> > EDAC MC: Ver: 3.0.0
> > AMD64 EDAC driver v3.4.0
> > EDAC amd64: DRAM ECC enabled.
> > EDAC amd64: NB MCE bank disabled, set MSR 0x0000017b[4] on node 0 to
enable.
> > EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will
not
> > load.
> > AMD64 EDAC driver v3.4.0
> > EDAC amd64: DRAM ECC enabled.
> > EDAC amd64: NB MCE bank disabled, set MSR 0x0000017b[4] on node 0 to
enable.
> > EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will
not
> > load.
> 
> Afaict the driver as is simply can't work in a Xen Dom0; it needs
> enabling (read: para-virtualizing). I'm actually glad to see it
doesn't
> load (the worse alternative would be for it to load and then do the
> wrong thing or give you a false sense of safety of your data).
I'm unsure of how to evaluate the situation.  Since ECC is enabled in the
BIOS, data should be safe whether or not the EDAC driver loads.  I
/suspect/ the EDAC driver failing to load merely means reportting of ECC
errors won't happen.  I suspect the only paravirtualization needed is to
map the physical address of the soft|hard errors to which VM's memory
range was effected.  What this effects is which VM should panic in case
of hard errors.

Depending upon the environment there may or may not be cause to report
soft errors anywhere beside Dom0.  In most cases a soft error will at
worst trigger a desire to replace the memory module, but not trigger a
panic for the affected VM.  It is only once a hard error occurs that it
is urgent to warn the effected VM and cause a panic; in this case it
may also be desireable to first alert Dom0 anyway.

As such I'm inclined to think force-enabling ECC EDAC monitoring in Dom0
is the best approach for now.  As long as a hard error doesn't occur in
Dom0's address range, Dom0 is in the best position to deal with the
situation.  The worst case is a hard error occuring in Xen's address
range, since that will mean all VMs on the machine are likely to be
toast.

I think this should be a fairly high priority for Xen since ECC memory is
a feature very common on systems running with a hypervisor.


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