OSDev.org

I just wrote a little code for HPET and tested under QEmu. It detects the address of the HPET registers properly according to the appropriate ACPI table.

After that I tried to disable the HPET timer with the -no-hpet parameter of QEmu, but the problem is that the HPET ACPI table is still present and valid according to its checksum. My question is that how should I detect that the HPET is disabled?

After checking some of the HPET registers for invalid values, such as the ID register with 0 value, I was able to figure out that the HPET is "invalid".

BTW, it would be better to not even include the HPET ACPI table if it's disabled ...

I don't see anything in the wiki on hpet. (Perhaps my blackberry is wacking out). If you could include ur findings for others it would be appreciated.

giszo wrote:BTW, it would be better to not even include the HPET ACPI table if it's disabled ...

That could be a bug in QEmu. Although I can imagine that if the HPETs can be enabled by software (BIOS?) that they'd be included in the ACPI tables anyway.


JAL

The tables are also generated by the BIOS and I'm not sure what should happen on real hardware. I'm just guessing here but if there was a real machine with a HPET that the BIOS doesn't put in the HPET mode (i.e., runs in PIT compatibility mode), the OS could read the ACPI tables and know it's a HPET and set it in the right mode. However, I doubt QEMU will actually emulate a HPET in PIT mode judging by the flag (i.e., "-no-hpet"). Thus, it's probably a bug in QEMU.

Unfortunately this kind of behavior is probably not formally specified anywhere. As if buggy ACPI tables weren't enough...