Re: [PATCH] hw/riscv: Fix type conflict of GLib function pointers

2025-04-13 Thread Alistair Francis
On Fri, Apr 11, 2025 at 2:19 AM Paolo Bonzini wrote: > > qtest_set_command_cb passed to g_once should match GThreadFunc, > which it does not. But using g_once is actually unnecessary, > because the function is called by riscv_harts_realize() under > the Big QEMU Lock. > > Reported-by: Kohei Tokun

Re: [PATCH] hw/riscv: Fix type conflict of GLib function pointers

2025-04-10 Thread Alistair Francis
On Fri, Apr 11, 2025 at 2:19 AM Paolo Bonzini wrote: > > qtest_set_command_cb passed to g_once should match GThreadFunc, > which it does not. But using g_once is actually unnecessary, > because the function is called by riscv_harts_realize() under > the Big QEMU Lock. > > Reported-by: Kohei Tokun

Re: [PATCH] hw/riscv: Fix type conflict of GLib function pointers

2025-04-10 Thread Philippe Mathieu-Daudé
On 10/4/25 18:17, Paolo Bonzini wrote: qtest_set_command_cb passed to g_once should match GThreadFunc, which it does not. But using g_once is actually unnecessary, because the function is called by riscv_harts_realize() under the Big QEMU Lock. Reported-by: Kohei Tokunaga Signed-off-by: Paolo

Re: [PATCH] hw/riscv: Fix type conflict of GLib function pointers

2025-04-10 Thread Kohei Tokunaga
Hi Paolo, I appreciate you addressing this issue and submitting the fix. Reviewed-by: Kohei Tokunaga

[PATCH] hw/riscv: Fix type conflict of GLib function pointers

2025-04-10 Thread Paolo Bonzini
qtest_set_command_cb passed to g_once should match GThreadFunc, which it does not. But using g_once is actually unnecessary, because the function is called by riscv_harts_realize() under the Big QEMU Lock. Reported-by: Kohei Tokunaga Signed-off-by: Paolo Bonzini --- hw/riscv/riscv_hart.c | 7 +