Bug #13039

HPET on AWS EC2 may be Hazard-Prone Error Trigger

Added by Joshua M. Clulow 8 months ago. Updated 7 months ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


Amazon provide a wide variety of virtual machine configurations in their cloud. Many of them advertise themselves as hardware virtualised Xen guests. These instances provide a number of Xen-specific paravirtualised facilities, such as a clock and timer source. In addition, some number of classical facilities are advertised and emulated, though the emulation is not always perfect.

In at least m4.16xlarge instance size, though notably not in the slightly smaller m4.10xlarge instance size, programming the HPET will immediately reset the guest instance. This also happens on current Ubuntu Linux, which I confirmed with the samples/timers/hpet_example.c program that ships with the Linux kernel. This program will open and engage the HPET from a user mode process (via /dev/hpet) on that system. In a 16x guest, it would reset immediately; in a 10x guest it would correctly program the timer and report various firings.

Because HPET support is of somewhat variable quality on AWS, we should refuse to program the HPET there. Amazon is a big user of Xen, and it is not hard to assume that this defect may appear in other Xen distributions as well; certainly we have had other unresolved issues on Xen platforms in the last few years (e.g., #8053, #8079, #9533, #5230, etc). We can gate on the HW_XEN_HVM bit in the return of get_hwenv() as was done for #9533 / #8079

Refusing to program the HPET will have the most impact on systems which do not offer the Always-Running APIC Timer (ARAT) CPU feature; on such systems, the LAPIC timer does not run in deep C-states and thus we need the HPET to wake CPUs up from that state. If the HPET is also unavailable, cpu_deep_cstates_supported() will return false and we will not use deep C-states at all. While this is somewhat less than ideal, it is also the way stock SmartOS systems have been shipping (for better or worse) for a number of years, as SmartOS includes a idle_cpu_no_deep_c override in /etc/system which has the same effect.

In a follow-up issue we could do the work to support the Xen timer source, which would enable us to use that as a proxy timer instead of the HPET. In the interim, this unabashed workaround will allow us to boot in more AWS instance types.

Also available in: Atom PDF