Re: [Xen-devel] heavy P2M lock contention on guest HPET counter reads

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.07.14 at 12:29, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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)

No, we wouldn't need to care about that mode. For one, the qemu
path should be unreachable for a well behaved guest, since with
"hpet=0" there's no ACPI table advertising a HPET. And then, even
if it was reachable (e.g. due to a guest guessing/probing it), I don't
think we need to be concerned about that path's performance.

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

I'm told this flag doesn't make any difference, albeit I'll have them
double check.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel