qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards


From: Jon Alduan
Subject: Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards
Date: Fri, 22 Jul 2022 09:57:41 +0200

Hi Peter,

yes, I see that too. I think you are right with your assumption.
Please, let me know as soon as you have a bugfix candidate. I will be of course, very pleased to test it :-)

Thank you for your support!!

Best regards
Jon

El jue, 21 jul 2022 a las 22:36, Peter Maydell (<peter.maydell@linaro.org>) escribió:
On Thu, 21 Jul 2022 at 20:03, Jon Alduan <jon.alduan@gmail.com> wrote:
>
> Here you have the output with the debug logs:
>
> next_free_host_timer: returning 0
> timer_create: host timer_create: returned 0x00000000, set phtimer 0x559dc5d8aa00 to (nil)
> timer_create: wrote 0xcaf0000 to guest address 0x408002e8
> Create timer 0 536880
> get_timer_id: guest timer id 0xcaf0000 -> index 0
> next_free_host_timer: returning 0
> timer_create: host timer_create: returned 0x00000000, set phtimer 0x559dc5d8aa00 to 0x1
> timer_create: wrote 0xcaf0000 to guest address 0x408002e8
> Create timer 1 537928
> get_timer_id: guest timer id 0xcaf0000 -> index 0
> next_free_host_timer: returning 1

For me I get:

next_free_host_timer: returning 0
timer_create: host timer_create: returned 0x00000000, set phtimer
0x562e7f755e20 to 0x562e81150040
timer_create: wrote 0xcaf0000 to guest address 0x407ffe90
Create timer 0 0x0x83520
get_timer_id: guest timer id 0xcaf0000 -> index 0
next_free_host_timer: returning 1
timer_create: host timer_create: returned 0x00000000, set phtimer
0x562e7f755e28 to 0x562e81215230
timer_create: wrote 0xcaf0001 to guest address 0x407ffe90
Create timer 1 0x0x83530
get_timer_id: guest timer id 0xcaf0001 -> index 1
next_free_host_timer: returning 2
timer_create: host timer_create: returned 0x00000000, set phtimer
0x562e7f755e30 to 0x562e81150720
timer_create: wrote 0xcaf0002 to guest address 0x407ffe90
Create timer 2 0x0x83540
get_timer_id: guest timer id 0xcaf0002 -> index 2
next_free_host_timer: returning 3
timer_create: host timer_create: returned 0x00000000, set phtimer
0x562e7f755e38 to 0x562e81150fc0
timer_create: wrote 0xcaf0003 to guest address 0x407ffe90
Create timer 3 0x0x83550
get_timer_id: guest timer id 0xcaf0003 -> index 3
next_free_host_timer: returning 4
timer_create: host timer_create: returned 0x00000000, set phtimer
0x562e7f755e40 to 0x562e81151200
timer_create: wrote 0xcaf0004 to guest address 0x407ffe90
Create timer 4 0x0x83560
get_timer_id: guest timer id 0xcaf0004 -> index 4

I think what is happening here is that for your system, the host
libc is returning timer ID values (host libc timer_t values)
which are integers 0, 1, 2, ... On my system the host libc returns
timer_t values which are pointers -- you can see they are
0x562e81150040, 0x562e81215230, etc.

The code in QEMU that determines "is this slot in the array
in use or not?" assumes that 0 is a value it can use to mark
"not used", ie that it is not a valid timer_t. That's clearly
a broken assumption. The effect is that when we're allocating
an ID for the second timer that gets created we look at the
slot that has the first timer's host timer_t ID, and because
on your system it's 0 we think it's not in use and reuse it.

Presumably your host has a different (older?) libc than mine,
which is why the difference.

Now I understand the cause of the bug I'll think about how to
best fix it, but I won't get to that until next week.

thanks
-- PMM


--
j.A

reply via email to

[Prev in Thread] Current Thread [Next in Thread]