On Fri, 20 Jun 2025 at 16:15, Igor Mammedov <imamm...@redhat.com> wrote:
>
> Reading QEMU_CLOCK_VIRTUAL is thread-safe.
>
> with CLI
> -M q35,hpet=on -cpu host -enable-kvm -smp 240,sockets=4
> patch makes WS2025 guest, that was able to boot in 4/2min, to boot in 2/1min.
>
> Signed-off-by: Igor Mammedov <imamm...@redhat.com>
> ---
> hw/timer/hpet.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
> index 0fd1337a15..1ebd715529 100644
> --- a/hw/timer/hpet.c
> +++ b/hw/timer/hpet.c
> @@ -681,6 +681,8 @@ static void hpet_init(Object *obj)
>
> /* HPET Area */
> memory_region_init_io(&s->iomem, obj, &hpet_ram_ops, s, "hpet",
> HPET_LEN);
> + memory_region_enable_lockless_ro_io(&s->iomem);
> + s->iomem.disable_reentrancy_guard = true;
> sysbus_init_mmio(sbd, &s->iomem);
Is this sequence possible?
thread A
takes the BQL
enters hpet_ram_write() for HPET_CFG to set ENABLE
executes s->config = new_val (setting the ENABLE bit in it)
context switch before it gets to the point of setting
s->hpet_offset
thread B
enters hpet_ram_read() for HPET_COUNTER (which it can now
do because it doesn't need the BQL)
hpet_enabled() returns true (it tests s->config)
calls hpet_get_ticks which adds hpet_offset to the clock,
but hpet_offset has not been correctly set by A yet
thanks
-- PMM
