mirror of
https://github.com/qemu/qemu.git
synced 2024-12-12 13:13:51 +08:00
19c417ec87
Coverity points out (CID 1507534, 1507968) that we sometimes access env->xen_singleshot_timer_ns under the protection of env->xen_timers_lock and sometimes not. This isn't always an issue. There are two modes for the timers; if the kernel supports the EVTCHN_SEND capability then it handles all the timer hypercalls and delivery internally, and all we use the field for is to get/set the timer as part of the vCPU state via an ioctl(). If the kernel doesn't have that support, then we do all the emulation within qemu, and *those* are the code paths where we actually care about the locking. But it doesn't hurt to be a little bit more consistent and avoid having to explain *why* it's OK. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Message-Id: <20230801175747.145906-3-dwmw2@infradead.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> |
||
|---|---|---|
| .. | ||
| hyperv-proto.h | ||
| hyperv-stub.c | ||
| hyperv.c | ||
| hyperv.h | ||
| kvm_i386.h | ||
| kvm-cpu.c | ||
| kvm-cpu.h | ||
| kvm-stub.c | ||
| kvm.c | ||
| meson.build | ||
| sev-stub.c | ||
| trace-events | ||
| trace.h | ||
| xen-compat.h | ||
| xen-emu.c | ||
| xen-emu.h | ||