Re: [Xen-devel] [RFC] x86: restore PCI SERR NMI forwarding to Dom0

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 17 Jan 2013, Jan Beulich wrote:
> >>> On 17.01.13 at 12:26, Stefano Stabellini 
> >>> <stefano.stabellini@xxxxxxxxxxxxx>
> wrote:
> > On Thu, 17 Jan 2013, Jan Beulich wrote:
> >> c/s 22949:54fe1011f86b removed the forwarding of NMIs to Dom0 when they
> >> were caused by PCI SERR. NMI buttons as well as BMCs (like HP's iLO)
> >> may however want such events to be seen in Dom0 (e.g. to trigger a
> >> dump).
> >> 
> >> I'm therefore suggesting to restore most of the functionality which
> >> named c/s removed (adjusted for subsequent changes, and adjusting the
> >> public interface to use the modern term, retaining the old one for
> >> backwards compatibility).
> > 
> > Allowing the possibility of injecting these events in Dom0 might be a
> > good idea (dom0 just ignores PCI SERR anyway if I recall correctly).
> > However the default for opt_nmi in Xen is "fatal", so if I am not
> > mistaken you are changing the default Xen behaviour from ignore PCI
> > SERR to break down on PCI SERR. I don't think that's a good idea.
> 
> #ifdef NDEBUG
> static char __read_mostly opt_nmi[10] = "dom0";
> #else
> static char __read_mostly opt_nmi[10] = "fatal";
> #endif
> 
> I.e. debug builds would die, but "normal" builds wouldn't. If the
> former is a problem, it's so not only for PCI SERR imo (and would
> need fixing here rather than in the patch I sent).

I didn't realize we inverted the DEBUG (NDEBUG now), so I misread the
condition.
Could we print a more relevant error message then? Not just "MEMORY ERROR",
but something about a PCI SERR.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel