[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 21.01.13 at 16:51, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
wrote:
> 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.

That's already the case:

static void pci_serr_softirq(void)
{
    printk("\n\nNMI - PCI system error (SERR)\n");
    outb(inb(0x61) & 0x0b, 0x61); /* re-enable the PCI SERR error line. */
}

Oh, you mean in the message before calling fatal_trap() - it's
an oversight of mine that this still prints MEMORY ERROR. I'll
get that fix and then submit as non-RFC if that's your only
concern.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.