RE: [Xen-devel] vpt periodic timer and vhpet

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Peter Johnston [mailto:Peter.Johnston@xxxxxxxxxx] 
>Sent: Saturday, February 07, 2009 8:50 AM
>
>Hi Kevin,
>
>One of the differences with the vpt logic is that missed ticks 
>will be delivered to the guest where the old logic would lose 
>them.  This would cause time loss in Windows guests as Windows 
>expects to get every clock tick, at a certain period, and 
>updates it's concept on that basis.  Windows doesn't reread 
>any h/w clocks (which is an expensive operation) (except in 
>the case of the kernel debugger where it knows it was spinning 
>with interrupts disabled ... I haven't thought of a good way 
>to drop interrupts in that case).  But I digress.

I understand the necessity to move vhpet to vpt. Your patch
description is very clear in the purpose. :-)

>
>My thinking was to try to stay more accurate to the h/w where 
>the timer's main clock is running when the period (ie the 
>comparator) is set.  When a match occurs, the comparator is 
>incremented by the value last written to it.  As the clock was 
>already running, that first due time may be much sooner, 
>especially in a virtual environment where the vcpu may have 
>been switched between zeroing the main counter and setting the 
>comparator.

Sure, that's the fact but my point is that we don't need emulate
this behavior, as for a periodic timer in virtualization environment
every virtual interrupt has possibility to be inaccurate, and that's
what vpt logic tries to compensate, e.g. catch up losing ticks
if timer mode is configured so. It doesn't worthy of special care
on 1st expiration although it's assumed to be fired sooner. 

Actually even with your change, the actual expiration is still
unknown, e.g. target vcpu could be pending in the run queue
with waiting time being dozens of milliseconds. You just make
it from [period, unknown] to [delta, unknown].

>
>Probably not really really needed but I didn't see any harm in 
>trying to make it work in a more accurate approximation of 
>that the guest would expect.
>
>Also, using separate due_time and period values seemed cleaner 
>to me than passing a Boolean to indicate if we were setting a 
>periodic timer in which case the due_time should be used as a period.
>

Then let it be. My comment is more about implementation choice
and of course your change is not a bad thing. Good thing is for me
to make sure that I didn't neglect any tricks behind. :-)

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