On 22.04.16 00:04, Peter Maydell wrote: > On 21 April 2016 at 22:41, Alexander Graf <agraf@xxxxxxx> wrote: >> So effectively all we'd need is to set CNTHCTL_EL2.EL1PCEN to 0 for >> guests that have no in-kernel irqchip, no? We should then trap on all >> timer accesses and be able to emulate them in user space where we can >> inject IRQs into an emulated GIC again. > > You'd still need to define a new userspace ABI for "we stopped > for a system register trap" and the userspace code to emulate > the timers as part of KVM rather than as part of TCG, which seems > like a lot of effort for a mode that you really don't want to be > using... It might make sense to have a generic "system register couldn't get handled" exit code anyway. If nothing else, at least to display unhandled registers in the qemu context where they appear rather than in the kernel log (which a guest could deliberately clutter as it stands today). With such an interface in place, the rest would only be a few lines of glue. > For GICv3 it gets trickier again because the interface between > the interrupt controller and the CPU is no longer as simple > as "an FIQ line and an IRQ line". (In particular the interrupt > controller needs to know the CPU's current exception level and > security state to know if it should raise IRQ or FIQ, which means > that it needs to be told every time the CPU changes EL. I haven't > yet figured out if I should model this in the QEMU emulated GICv3 > by having a backdoor callback function for this or by biting > the bullet and putting the GICv3 cpu interface really in the > CPU with a properly modelled equivalent of the stream protocol...) We moved the lapic into target-i386 as well, no? Given that it really is very close to the cpu these days it might not be a bad idea. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
