Re: [Patch v5 2/5] x86/hpet: Use singe apic vector rather than irq_descs for HPET interrupts

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 25/11/13 07:50, Jan Beulich wrote:
>>>> On 22.11.13 at 17:23, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 22/11/13 15:45, Jan Beulich wrote:
>>>>>> On 14.11.13 at 17:01, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> The new logic is as follows:
>>>>  * A single high priority vector is allocated and uses on all cpus.
>>> Does this really need to be a high priority one? I'd think we'd be
>>> fine with the lowest priority one we can get, as we only need the
>>> wakeup here if nothing else gets a CPU to wake up.
>> Yes - absolutely.  We cannot have an HPET interrupt lower priority than
>> a guest line level interrupt.
>>
>> Another cpu could be registered with our HPET channel to be worken up,
>> and we need to service them in a timely fashon.
> Which I meanwhile think hints at an issue with the (re)design:
> These wakeups, from an abstract pov, shouldn't be high
> priority interrupts - they're meant to wake a CPU only when
> nothing else would wake them in time. And this could be
> accomplished by transferring ownership of the channel during
> wakeup from the waking CPU to the next one to wake.
>
> WHich at once would eliminate the bogus logic selecting a channel
> for a CPU to re-use when no free one is available: It then wouldn't
> really matter which one gets re-used (i.e. could be assigned in e.g.
> a round robin fashion).
>
> The fundamental requirement would be to run the wakeup (in
> particular channel re-assignment) logic not just from the HPET
> interrupt, but inside an exit_idle() construct called from all IRQ
> paths (similar to how Linux does this).
>
> Jan
>

Irrespective of the problem of ownership, the HPET interrupt still needs
to be high priority.  Consider the following scenario:

* A line level interrupt is received on pcpu 0.  It is left outstanding
at the LAPIC.
* A domain is scheduled on pcpu 0, and has has an event injected for the
line level interrupt.
* The event handler takes a long time, and during the process, the
domains vcpu is rescheduled elsewhere
* pcpu0 is now completely idle and goes to sleep.

This scenario has pcpu 0 going to sleep with an outstanding line level
irq unacked at the LAPIC, with a low priority HPET interrupt blocked
until the domain has signalled the completion of the event.

There is no safe scenario (given Xen's handling of line level interrupt)
for timer interrupts to be lower priority than the highest possible line
level priority.

~Andrew