Hi,
On 7/27/19 12:13 PM, Marc Zyngier wrote:
On Fri, 26 Jul 2019 23:58:38 +0100,
Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
On Wed, 24 Jul 2019, Marc Zyngier wrote:
On 23/07/2019 18:58, Julien Grall wrote:
It really feels like a change in hrtimer_cancel semantics. From what I
understand, this is used to avoid racing against the softirq, but boy it
breaks things.
If this cannot be avoided, this means we can't cancel the background
timer (which is used to emulate the vcpu timer while it is blocked
waiting for an interrupt), then we must move this canceling to the point
where the vcpu is unblocked (instead of scheduled), which may have some
side effects -- I'll have a look.
But that's not the only problem: We also have hrtimers used to emulate
timers while the vcpu is running, and these timers are canceled in
kvm_timer_vcpu_put(), which is also called from a preempt notifier.
Unfortunately, I don't have a reasonable solution for that (other than
putting this hrtimer_cancel in a workqueue and start chasing the
resulting races).
The fix is simple. See below. We'll add that to the next RT release. That
will take a while as I'm busy with posting RT stuff for upstream :)
Ah, thanks for that! And yes, looking forward to RT upstream, it's
just about time! ;-)
Thanks,
tglx
8<------------
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -80,7 +80,7 @@ static inline bool userspace_irqchip(str
static void soft_timer_start(struct hrtimer *hrt, u64 ns)
{
hrtimer_start(hrt, ktime_add_ns(ktime_get(), ns),
- HRTIMER_MODE_ABS);
+ HRTIMER_MODE_ABS_HARD);
}
That's pretty neat, and matches the patch you already have for
x86. Feel free to add my
Acked-by: Marc Zyngier <maz@xxxxxxxxxx>
I can confirm the warning now disappeared. Feel free to added my tested-by:
Tested-by: Julien Grall <julien.grall@xxxxxxx>
Thank you both for the help!
Cheers,
--
Julien Grall
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
