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

[Peter Maydell]

On Thu, 21 Jul 2022 at 14:10, Jon Alduan <jon.alduan@gmail.com> wrote:
> Yes, exactly. When removing timer 0, time 1 will be removed instead.
> Other timers are not affected. If you create a dummy timer 0, there
> are no more problems (that I can address).

Yeah, but it's complicated, because there are multiple "timer IDs" here:

 * in the guest source code, the "timer_t" type is actually a void*
   (which is why you get compiler warnings about printing it as an
   integer). This timer_t type is provided by the libc, and in glibc
   it's a pointer to a struct that glibc allocates per-timer when
   the guest test program calls the glibc timer_create() function
 * there is the guest kernel timer ID value, which is a 32 bit
   integer. From the guest libc's point of view, when it makes the
   timer_create syscall, the kernel allocates this value, and
   glibc is responsible for mapping back and forth between the
   pointer-value timer_t the guest code uses and the integer value
   the kernel uses
 * within QEMU, we have to manage those guest-kernel timer ID values;
   for our implementation they're always a fixed magic number in
   the high 16 bits, and an index value between 0 and 31 in the
   low 16 bits. QEMU has to map back and forth between the guest
   kernel timer ID values and host glibc timer_t values, because
   it implements the guest syscall by calling the host glibc
   timer_create(). The host timer_t values are pointers, again.
 * the host libc does exactly the same thing as the guest libc
   where it hands out timer_t values which are pointers and
   maps between those and the host kernel's integer timer IDs.

So when we look at the host strace and see "timer ID 0 is being
deleted", that's the host kernel timer ID; and there's a fair
amount of complicated code in the guest between the test program's
"call timer_create()" and when it actually gets into QEMU...

-- PMM