[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH] Port HPET device model to vpt timer subsystem

  • To: "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Tue, 21 Oct 2008 09:56:56 +0100
  • Cc: Peter Johnston <Peter.Johnston@xxxxxxxxxx>
  • Delivery-date: Tue, 21 Oct 2008 01:57:32 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AckzWvgkNr7lbJ9OEd2v1AAX8io7RQ==
  • Thread-topic: [PATCH] Port HPET device model to vpt timer subsystem

The current hpet implementation runs a one-shot xen timer for each hpet
timer whenever the main counter is enabled regardless of whether or not the
individual hpet timers are enabled.  When the timer fires, if it is enabled
the interrupt is routed to the guest.  If the hpet timer is periodic, a new
one-shot timer is set, for NOW()+period.  There are a number of problems
with this the most significant is guest time drift.  Windows does not read
the hardware clock to verify time, it depends on timer interrupts firing at
the expected interval.  The existing implementation queues a new one-shot
timer each time it fires and does not allow for a difference between NOW()
and the time the timer was expected to fire, causing drift.  Also there is
no allowance for lost ticks. This modification changes HPET to use the
Virtual Platform Timer (VPT) and, for periodic timers, to use periodic
timers.  The VPT ensures an interrupt is delivered to the guest for each
period that elapses, plus, its use of xen periodic timers ensures no drift.
Signed-off-by: Peter Johnston <peter.johnston@xxxxxxxxxx>

Attachment: hvm-hpet-vpt
Description: Binary data

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.