HPET virtualization

HPET virtualization

Imagen de Tracy Camp
Tracy Camp
Sáb, 19/11/2011 - 16:53

I've finally gotten my APIC emulation to the point that I'm able to selectively deliver interrupts from the APIC to a guest succesfully. As part of this I'm setting the external interrupt control and maniputing the TPR and interrupt window controls. Like many hypervisor projects I'm starting with a machine that has booted an operating system and am taking control of the hardware from this operating system as I launch my hypervisor. My current issue seems to be that the HPET timer as previously programmed by the Windows OS triggers interrupts in a fashion that the overhead of intercepting the interrupt from the APIC and delivering it through my virtualization code leads to a sort of 'live lock' with the guest domain effectively making no forward progress and eventually bug checking with a DPC timer watchdog exception. Does this sound like a general problem with the efficency of my hypervisor interrupt handling code or is there some general advise for handling system resources like the HPET within hypervisors that I'm not presenty aware of, or does this sound like some other form of bug - like perhaps I need to do more than simply send EOI to the local APIC to de-assert the HPET device? Thanks for any input!

RSS Superior
publicaciones de 2 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de David Ott (Intel)
David Ott (Intel)
Mié, 30/11/2011 - 10:48

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

Superior

Inicie sesión para dejar un comentario.