Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Ulrich Obergfell <uobergfe@redhat.com>]

On 02/03/2011 9:07 PM, Anthony Liguori wrote:
> On 02/03/2011 09:28 AM, Jan Kiszka wrote:
>> On 2011-02-03 14:43, Ulrich Obergfell wrote:
...
>>> This is an RFC through which I would like to get feedback on how the
>>> idea of a patch to compensate those lost interrupts would be received:
>>>
>>> The patch determines the number of lost timer interrupts based on the
>>> number of elapsed comparator periods. Lost interrupts are compensated
>>>
>> That neglects coalescing of the HPET IRQs: If the timer is run regularly
>> but the guest is not able to retrieve the injected IRQs, you should
>> still see drifts with your patches.
>>
> 
> FWIW, this isn't the most common failure scenario. This is only really
> prominent when you have rapid reinject like we do with the in-kernel
> PIT. This generally shouldn't be an issue with gradual reinjection.
> 
>>> by gradually injecting additional interrupts during the subsequent
>>> timer intervals, starting at a rate of one additional interrupt per
>>> interval. If further interrupts are lost while compensation is still
>>> in progress, the rate is increased. The algorithm imposes a limit on
>>> the rate and on the 'backlog' of lost interrupts to be injected.


Anthony, Jan,

many thanks for your feedback. I'm sorry for not responding earlier.

I used the following KVM kernel module trace point in __apic_accept_irq()
to trace coalesced interrupts related to HPET timer 0:

        result = !apic_test_and_set_irr(vector, apic);
        trace_kvm_apic_accept_irq(vcpu->vcpu_id, delivery_mode,
                                  trig_mode, vector, !result);

While running the test outlined in my original email, I observed between
5 and 15 of these events occurring during one minute:

 qemu-system-x86-7632  [000]  3755.888909: kvm_apic_accept_irq: apicid 0
 vec 209 (Fixed|edge) (coalesced)

kvm->arch->vioapic.redirtbl[2] indicated that IRQ 2 was routed to vector
number 209.

With a comparator period of 15.6 milliseconds, the coalesced interrupts
apparently contribute less than 250 milliseconds of drift. However, the
total drift that I observed during one minute was up to 15 seconds.

I think the patch could possibly handle coalesced interrupts too:

- In update_irq(), use a similar method as in RTC emulation to detect
  coalesced interrupts. Return a delivery status to hpet_timer().

- In hpet_timer(), decrement t->irqs_to_inject (number of interrupts
  remaining to inject) only if the interrupt was not coalesced.


Regards,

Uli Obergfell