On Thu, 25 Apr 2019 13:57:40 +0100,
Andre Przywara <andre.przywara@xxxxxxx> wrote:
>
> From: Christoffer Dall <christoffer.dall@xxxxxxx>
>
> When a VCPU never runs before a guest exists, but we set timer registers
> up via ioctls, the associated hrtimer might never get cancelled.
>
> Since we moved vcpu_load/put into the arch-specific implementations and
> only have load/put for KVM_RUN, we won't ever have a scheduled hrtimer
> for emulating a timer when modifying the timer state via an ioctl from
> user space. All we need to do is make sure that we pick up the right
> state when we load the timer state next time userspace calls KVM_RUN
> again.
>
> We also do not need to worry about this interacting with the bg_timer,
> because if we were in WFI from the guest, and somehow ended up in a
> kvm_arm_timer_set_reg, it means that:
>
> 1. the VCPU thread has received a signal,
> 2. we have called vcpu_load when being scheduled in again,
> 3. we have called vcpu_put when we returned to userspace for it to issue
> another ioctl
>
> And therefore will not have a bg_timer programmed and the event is
> treated as a spurious wakeup from WFI if userspace decides to run the
> vcpu again even if there are not virtual interrupts.
>
> This fixes stray virtual timer interrupts triggered by an expiring
> hrtimer, which happens after a failed live migration, for instance.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@xxxxxxx>
> Reported-by: Andre Przywara <andre.przywara@xxxxxxx>
> Tested-by: Andre Przywara <andre.przywara@xxxxxxx>
> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>
Fixes: bee038a674875 ("KVM: arm/arm64: Rework the timer code to use a
timer_map")
Applied to -master.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
