[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: |
Peter Maydell |
Subject: |
Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards |
Date: |
Thu, 21 Jul 2022 14:44:04 +0100 |
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
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, (continued)
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Peter Maydell, 2022/07/20
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Jon Alduan, 2022/07/20
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Peter Maydell, 2022/07/20
- Message not available
- Message not available
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Jon Alduan, 2022/07/20
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Peter Maydell, 2022/07/20
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Jon Alduan, 2022/07/20
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Peter Maydell, 2022/07/21
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Jon Alduan, 2022/07/21
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Peter Maydell, 2022/07/21
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Jon Alduan, 2022/07/21
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards,
Peter Maydell <=
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Peter Maydell, 2022/07/21
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Jon Alduan, 2022/07/21
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Peter Maydell, 2022/07/21
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Jon Alduan, 2022/07/22
- Re: [qemu-arm-static] timer_delete issue from Qemu 5.0.0 onwards, Peter Maydell, 2022/07/25