I obtained qemu code and looked through hw/hpet.c, below are some observations.
on 21/07/2009 15:29 Andriy Gapon said the following:
I observe the following problems with qemu-emulated HPET:
1. setting lower 32bits of a 64-bit register clears the higher 32 bits;
At least this happens with TIMn_CONF register - I set some bits at offset 0x100
and all bits at 0x104 become cleared. The problem is aggravated by the fact that
those bits are supposed to be RO - they specify interrupt routing capabilities.
This probably happens because of the following.
New value is set using a filter function, e.g.:
timer->config = hpet_fixup_reg(new_val, old_val,
HPET_TN_CFG_WRITE_MASK);
But old_val was set to:
old_val = hpet_ram_readl(opaque, addr);
Apparently hpet_ram_readl returns value in the lower 32 bits and thus higher 32
bits are lost.
timer->config is a 64-bit variable that is supposed to hold all bits of
TIMn_CONF
(judging from hpet_ram_readl).
2. Setting interrupt type to level-triggered has no effect in the sense that
interrupt status bits are not set in GINTR_STA when interrupts are generated.
From the code I see that level-triggered interrupts are not supposed to be
supported at all:
if (new_val & HPET_TIMER_TYPE_LEVEL) {
printf("qemu: level-triggered hpet not supported\n");
exit (-1);
}
The code is quite harsh in calling exit(), but it is incorrect too.
This how HPET_TIMER_TYPE_LEVEL is defined:
#define HPET_TIMER_TYPE_LEVEL 1
#define HPET_TIMER_TYPE_EDGE 0
But Interrupt Type is bit #1 in TIMn_CONF, bit #0 is reserved and is typically
zero. The check should be:
if (new_val & (HPET_TIMER_TYPE_LEVEL << 1))
or something like that.
But maybe level-triggered HPET interrupts could be supported after all.