Hello!
Since c2f58514cfb374d5368c9da945f1765cd48eb0da ("arm/arm64: KVM: vgic: Check
for
!irqchip_in_kernel() when mapping resources") we can run qemu with
kernel_irqchip=off option. The
only remaining problem is how to handle CP15 timer in this case.
I have applied my old experimental patches to kernel 4.2.2. Using them, i can
run 'virt' machine
with software-emulated GICv2 on GICv3 hardware without v2 backwards
compatibility. Also, i studied
4.3 code, and it seems to be feasible to add this support to 4.3 and on.
The only main question now is how would we do it. We can actually use two
possible approaches:
1. If there's no in-kernel irqchip, we revert to older timer behavior
(ARCH_TIMER_CTRL_IT_MASK
hack), and forward the timer IRQ to userspace using new KVM_EXIT_IRQ return
code. Timer IRQ has to
be treated as edge-triggered in this case. This is the approach which my
current implementation
uses.
2. Another possible approach, based on how device tree binding is handled by
Linux. It is possible
to remove virtual timer IRQ from the device tree, in this case the kernel
reverts to using physical
timer. When running under hypervisor, accesses to physical CP15 timer are
trapped into HYP,
therefore we can forward them to userspace using new exit code, something like
KVM_EXIT_REG_ACCESS.
In this case the timer would be also emulated by the userspace, which is
slower, but allows better
emulation. Also, this could be used in order to run some other guests which
just expect physical
timer to be there.
Both approaches have their own limitations, but anyway this is much better
than nothing. What do
you think, and which approach do you like more?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
