Re: [Xen-devel] HPET Stack overflow

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.09.13 at 19:00, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On this particular hardware, using "maxcpus=4" does work around the
> issue, but is not a valid fix.  Playing with the position of
> ack_APIC_irq() does appear to affect the problem (as suspected), but I
> am not convinced it is the correct fix either.

I'm more and more convinced that this was wrong from the
beginning, and hence should be fixed independent of any
other adjustments for the specific problem of yours.

> Having looked at the implementation, which uses regular irqs and irq
> migration, I have to admit to being surprised it even works in the
> slightest.  For safety reasons, the irq migration code requires a irq to
> arrive at the old cpu, at which point state gets updates to point it at
> the new cpu.  It also means that the vector is essentially random
> between 0x21 and 0xef, which plays havoc with priorities of other
> interrupts, including line level interrupts (where a high priority line
> level interrupt with its ack sitting on the pending EOI stack can block
> a a lower priority HPET timer interrupt for an indefinite period of
> time).  From my reading of the code, a pcpu which calls
> hpet_get_channel() and needs to share channels will cause an early HPET
> interrupt to occur on the old pcpu, which appears to then go out of its
> way to wake up the cpu which should have received the interrupt.
> 
> It occurs to me that a substantially more sane method of doing this is
> to install a high priority handler with the hpet handler directly wired
> in.  This way, hpet_get_channel() becomes vastly more simple and just
> involves rewriting the MSI to change the destination.  It also allows
> for correct use of ack_APIC_irq() (i.e. prevent reentrancy), and frees
> up some space in the dynamic range.
> 
> Jan: as the author of the current code, is there anything I have overlooked?

That sounds all quite plausible. And no, I'm not the author of the
current code. I'm just the author of a lot of other adjustments to
the original implementation done by Intel folks, which - as we see
now - still weren't enough to get this into a sane state.

Jan


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