[Xen-devel] Re: [PATCH] xen: always handle VIRQ_TIMER first.

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

 On 10/15/2010 11:30 AM, Keir Fraser wrote:
> On 15/10/2010 18:18, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx> wrote:
>
>>  On 10/15/2010 03:52 AM, Ian Campbell wrote:
>>> This ensures that system is updated before calling any hard irq
>>> handlers after a long period of ticklessness. If we do not do this
>>> then hardirq will see a jiffies from before the period of ticklessness
>>> and make intcorrect decisions regarding timer expiry etc.
>>>
>>> This resolves issues e.g. with USB keyboard timer repeats.
>>>
>>> Based on a patch by Keir Fraser.
>> I talked about this with James, and it makes no sense to me at all.
> When guest resumes execution after a long period blocked, the unblocking
> interrupt may be handled before the inevitable timer interrupt which

Why "inevitable"?  What if the next timer event is still some time in
the future?  Or are you assuming the timer is driven by the default Xen
100Hz timer?

> actually syncs up jiffies to current system time. The unblocking interrupt
> sees old jiffies -- most hardirq handlers really don't care about time, but
> it happens that USB keyboard repeat is handled at that level -- it sees the
> key pressed at old jiffies and not released until new jiffies plus small
> delta. The difference between old and new jiffies can easily be enough to
> cause phantom key repeats.

Yes, but...

If the system is idle and has disabled timer ticks, and the next
interrupt is from a piece of hardware, then jiffies will be out of date,
but there won't necessarily be a pending timer tick.  If a device
interrupt handler is allowed to rely on jiffies, then there must be some
generic mechanism to update jiffies before calling any interrupt
handler.  This situation doesn't seem like it is in any way Xen
dependent, and AFAIK there's no general requirement that timer
interrupts be handled first. 

I'm guessing that this particular problem in the forward-port Xen kernel
as a side-effect of its bespoke time handling code (including
IDLE_NO_HZ) which is not doing something that the core time
infrastructure would normally do.  (I don't see why the forward-port
kernels couldn't use the existing Xen time support in mainline rather
than replacing it.)

Or perhaps there is a real bug here, but again, I don't think it is
Xen-specific, or be addressed in Xen code.

> One question of course is whether the same hardirq key repeat mechanism can
> be foxed simply be involuntary preemption of the guest. I suppose it could,
> but it's vastly more unlikely than the systematic deterministic race
> introduced by resume-from-block. Also we would hope that a runnable guest
> would not be descheduled for as long periods as a guest can be voluntarily
> blocked (bit arm waving that one I'll admit ;-).

I've seen unexpected key repeats in guests when using kvm keyboards.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel