aboutsummaryrefslogtreecommitdiff
path: root/hw
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw@amazon.co.uk>2023-05-22 20:52:00 +0200
committerPhilippe Mathieu-Daudé <philmd@linaro.org>2023-08-01 23:52:23 +0200
commit19c417ec87a446ffd1a13eeec23226fe30f31b7e (patch)
tree9cc5c59438406b287b08a1f165766022310a204e /hw
parentcf885b19579646d6a085470658bc83432d6786d2 (diff)
downloadqemu-19c417ec87a446ffd1a13eeec23226fe30f31b7e.zip
qemu-19c417ec87a446ffd1a13eeec23226fe30f31b7e.tar.gz
qemu-19c417ec87a446ffd1a13eeec23226fe30f31b7e.tar.bz2
i386/xen: consistent locking around Xen singleshot timers
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>
Diffstat (limited to 'hw')
0 files changed, 0 insertions, 0 deletions