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

Re: [Xen-devel] x86: adjust handling of interrupts coming in via legacy vectors



On Mon, May 14, 2012 at 11:43 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>
> >>> On 14.05.12 at 18:24, Keir Fraser <keir@xxxxxxx> wrote:
> > On 14/05/2012 16:56, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> >
> >>> Looks sensible, and I suppose good to have for 4.2.
> >>>
> >>> Acked-by: Keir Fraser <keir@xxxxxxx>
> >>
> >> Please take a look at the v2 I just sent, to accommodate a suggestion
> >> from Andrew Cooper.
> >
> > I think it's very paranoid, since legacy vectors never get programmed
> > into
> > an IOAPIC RTE and should never need EOIing at the local APIC. But you do
> > at
> > least printk the case that we see the ISR bit set, and you printk the
> > vector
> > number, so really this v2 patch gives us more information about this
> > bogus
> > situation than v1 did, so it's a slight improvement overall. So you
> > still
> > have my Ack.
>
> It indeed is paranoid (which is why I didn't do so in v1), but Andrew
> certainly has a point in saying that something so far unexplainable
> going on makes it desirable to cover as many (however remotely)
> potential causes as possible. (I still consider double delivery through
> IO-APIC and PIC the most likely scenario, despite not having a
> reasonably explanation on how the PIC mask bit could get cleared.)
>
> Once we hopefully understand the hole situation, the code here
> should likely be reverted to the v1 version (along with removing the
> other debugging code).

Once this patch goes in, do I need to still run with the patch Andrew
provided in http://lists.xen.org/archives/html/xen-devel/2012-05/msg00332.html
for the debugging code?

Thanks,
AP

_______________________________________________
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®.