On 14/08/15 13:26, Pavel Fedin wrote:
> Hello! Thank you for quick response.
>
>> This is fairly unreadable. Please use a switch statement instead.
>
> Christoffer disliked it in v1, so i thought a bit and changed it. Ok, will
> change it back.
>
>> And here, we're going to assume that the arch timer still usable. We
>> definitely need a way to *prevent* the timer to be used when there is no
>> GIC. Otherwise, we're going to start trying to setup the mapping for the
>> active state, and the guest may start poking it.
>
> But, this seems to be already done, isn't it?
> According to http://lxr.free-electrons.com/source/arch/arm/kvm/arm.c#L439:
> --- cut ---
> 459 /*
> 460 * Enable the arch timers only if we have an in-kernel VGIC
> 461 * and it has been properly initialized, since we cannot handle
> 462 * interrupts from the virtual timer with a userspace gic.
> 463 */
> 464 if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
> 465 kvm_timer_enable(kvm);
> --- cut ---
Right, I failed to remember that one. Sorry. It should be safe then.
Hopefully.
[...]
> And some more. Actually, it is possible to emulate generic timer in
> userspace, just not the virtual
> one. IIRC access to physical timer can be trapped. So, if we modify guest's
> device tree by removing
> virtual timer IRQ, the guest will fall back to physical timer. And this will
> be caught by the
> hypervisor. After this all we have to do is to add corresponding exit code
> which would allow the
> userspace to emulate missing CP15 (or system in case of ARM64) registers. So,
> this timer issue is
> not grave, just i postpone implementing it until GIC issues are settled down.
This is completely Linux-specific, unfortunately. And it relies on
userpace to expose a modified DT, so you need to be able to report back
to userspace that you can't deal with the virtual timer.
Which brings me to the next point: how do you tell userspace that your
timers are non-functional?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
