On Tue, 2019-07-30 at 13:26 +0200, Paolo Bonzini wrote:
> On 29/07/19 13:57, Anup Patel wrote:
> > + if (delta_ns > VCPU_TIMER_PROGRAM_THRESHOLD_NS) {
> > + hrtimer_start(&t->hrt, ktime_add_ns(ktime_get(),
> > delta_ns),
>
> I think the guest would prefer if you saved the time before enabling
> interrupts on the host, and use that here instead of ktime_get().
> Otherwise the timer could be delayed arbitrarily by host interrupts.
>
> (Because the RISC-V SBI timer is relative only---which is
> unfortunate---
Just to clarify: RISC-V SBI timer call passes absolute time.
https://elixir.bootlin.com/linux/v5.3-rc2/source/drivers/clocksource/timer-riscv.c#L32
That's why we compute a delta between absolute time passed via SBI and
current time. hrtimer is programmed to trigger only after the delta
time from now.
> guests will already pay a latency price due to the extra
> cost of the SBI call compared to a bare metal implementation.
Yes. There are ongoing discussions to remove this SBI call completely.
Hopefully, that will happen before any real hardware with
virtualization support shows up :).
> Sooner or
> later you may want to implement something like x86's heuristic to
> advance the timer deadline by a few hundred nanoseconds; perhaps add
> a
> TODO now).
>
I am not aware of this approach. I will take a look. Thanks.
Regards,
Atish
> Paolo
>
> > + HRTIMER_MODE_ABS);
> > + t->is_set = true;
> > + } else
> > + kvm_riscv_vcpu_set_interrupt(vcpu, IRQ_S_TIMER);
> > +
>
> _______________________________________________
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
