[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] heavy P2M lock contention on guest HPET counter reads
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |