Just noted vpt create_periodic_time is now changed to require two parameters: period and delta, by 18694 which ports vhpet to vpt framework. I''m not quite clear the necessity here. It doesn''t matter whether 1st expiration must be accurately hit. vhpet main counter and per-channel comparators are updated only when guest tries to read. Is there any special tricks on hpet since all other periodic timers are simply filling same value for period and delta? I ask because we''re considering some proactive timer alignment besides existing range timer, while above change seems to implicate something that we may neglect. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 06/02/2009 03:55, "Tian, Kevin" <kevin.tian@intel.com> wrote:> Just noted vpt create_periodic_time is now changed to require > two parameters: period and delta, by 18694 which ports vhpet > to vpt framework. I''m not quite clear the necessity here. It doesn''t > matter whether 1st expiration must be accurately hit. vhpet > main counter and per-channel comparators are updated only > when guest tries to read. Is there any special tricks on hpet > since all other periodic timers are simply filling same value for > period and delta? > > I ask because we''re considering some proactive timer alignment > besides existing range timer, while above change seems to implicate > something that we may neglect.See the changeset that introduced the delta (18694), see the changeset comment and the comment above use of create_periodic_time() in hpet.c. Decide if you agree, and if you don''t then ask the author, cc''ing the list. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >Sent: Friday, February 06, 2009 4:24 PM > >On 06/02/2009 03:55, "Tian, Kevin" <kevin.tian@intel.com> wrote: > >> Just noted vpt create_periodic_time is now changed to require >> two parameters: period and delta, by 18694 which ports vhpet >> to vpt framework. I''m not quite clear the necessity here. It doesn''t >> matter whether 1st expiration must be accurately hit. vhpet >> main counter and per-channel comparators are updated only >> when guest tries to read. Is there any special tricks on hpet >> since all other periodic timers are simply filling same value for >> period and delta? >> >> I ask because we''re considering some proactive timer alignment >> besides existing range timer, while above change seems to implicate >> something that we may neglect. > >See the changeset that introduced the delta (18694), see the changeset >comment and the comment above use of create_periodic_time() in hpet.c. >Decide if you agree, and if you don''t then ask the author, >cc''ing the list. >I read those comments, and agree that 1st expected expiration from now could be different from period, but I don''t see the necessity to emulate this difference for a periodic timer, since later expirations could be also inaccurate which is handled by vpt logic. Then why 1st trigger needs special care? CC peter now. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Peter Johnston [mailto:Peter.Johnston@citrix.com] >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@lists.xensource.com http://lists.xensource.com/xen-devel