Re: heavy P2M lock contention on guest HPET counter reads

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 30/07/14 11:08, Jan Beulich wrote:
> Hi,
>
> with 40+ vCPU Win2012R2 guests we're observing apparent guest live
> locks. The 'd' debug key reveals more than half of the vCPU-s doing an
> inlined HPET main counter read from KeQueryPerformanceCounter(),
> resulting in all of them racing for the lock at the beginning of
> __get_gfn_type_access(). Assuming it is really necessary to always
> take the write lock (rather than just the read one) here, would it perhaps
> be reasonable to introduce a bypass in hvm_hap_nested_page_fault()
> for the HPET page similar to the LAPIC one?
>
> Thanks, Jan

We have received similar concerns about the emulation overhead of the
vhpet, but not with a guest that size.

One complication is that the HPET can optionally be emulated by qemu
based on an HVMPARAM, so the fastpath has to consider creating an
ioreq.  (Frankly, I think this ability is completely mad, and I doubt
anyone would notice if it ceased to work.  There is no reason to use
qemu's emulation in preference to Xen's, especially as Xen's emulatator
was copied from qemu at some point in the past)

Have you enabled with viridian extensions?  Providing the TSC
enlightenments should cause Windows to completely ignore the vhpet.

~Andrew