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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.11.13 at 17:23, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/11/13 15:45, Jan Beulich wrote:
>>>>> On 14.11.13 at 17:01, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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


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