- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I pinged a couple of experts on your issue. One made the short comment that there appears to be some kind of bug in the way your interrupt is being virtualized by the VMM.
The other offers a more lengthy set of recommendations:
Therere at least two possible causes. First, the ownership switch of HPET between Windows and Hypervisor results in losing an effective HPET interrupt. If HPET is programmed in a single shot manner, any loss of an interrupt instance would not make forward progress since next interrupt has to wait for a full wrap of the HPET counter.
Second, its possible that the ownership switch happens at anunsafe point, e.g. when Windows is still populating HPET resources. There areseveral things you mighttry on this note:
a) Are thereany HPET interrupts after the ownership switch, or does the issue happen randomly with some HPET interrupts observed already?
b) Try readingback HPET counter/compare registers just after an ownership switch. Are things correct?
c) Add a timer (e.g. 1ms, less than DPC timer watchdog period) which periodically checks HPET registers and throws out warnings proactively.
d) If the physical HPET interrupt happens normally, its possibly related to the virtual interrupt delivery path. This keycode path and related statesshould be carefully checked to see whether virtual HPET timer injection is allowable by the Windows guest.
Hope this helps.
David Ott
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page