i386/xen: consistent locking around Xen singleshot timers
authorDavid Woodhouse <dwmw@amazon.co.uk>
Mon, 22 May 2023 18:52:00 +0000 (20:52 +0200)
committerPhilippe Mathieu-Daudé <philmd@linaro.org>
Tue, 1 Aug 2023 21:52:23 +0000 (23:52 +0200)
commit19c417ec87a446ffd1a13eeec23226fe30f31b7e
tree9cc5c59438406b287b08a1f165766022310a204e
parentcf885b19579646d6a085470658bc83432d6786d2
i386/xen: consistent locking around Xen singleshot timers

Coverity points out (CID 15075341507968) 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>
target/i386/kvm/xen-emu.c