On Wed, Jul 11, 2012 at 10:06 AM, Marc Zyngier <maz@xxxxxxxxxxxxxxx> wrote: > On 11 Jul 2012, at 08:30, Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx> > wrote: > > > On Jul 10, 2012 2:57 PM, "Marc Zyngier" <marc.zyngier@xxxxxxx> wrote: >> >> While we have to take host interrupts in HYP mode while running a >> guest, calling __irq_svc ourself is quite controvertial. > > Yes, I've been waiting for this comment for ~ 2 years now:) back then I knew > nothing about how a gic works. > > Here you go! :) I wasn't too worried about it until I really understood the > complexity of the calling convention. And noticing the EXPORT_SYMBOL was the > nail on the coffin. No way we'd leave a module to be able up inject > interrupts back in the kernel, this is way too abuse prone ;-). > >> And actually, we can let the kernel do its magic without getting in >> the way. Let's just return to SVC and enable interrupts. This should >> be enough for the CPU to notice that an interrupt is pending, and >> handle the interrupt the normal way. > > That is indeed much nicer. And this should work for all gic's and interrupt > models (level/edge), as you would always need to assert *something* to lower > the IRQ line, right? > > Yes. We simply don't involve the interrupt controller at all, and rely on > the IRQ line being asserted at the CPU level. The drawback is that we > actually take the exception twice (once in HYP, once in SVC), which is a bit > harder to follow. > > I've reworked this a bit yesterday, moving the kvm_arm_set_running_vcpu() > calls to vcpu_load/put(). This makes the code rather neat, without the > worrying proximity of enabling the interrupts and calling > kvm_arm_set_running_vcpu(NULL). I've pushed the patches to my vgic branch if > you want to have a look. > >> >> Maybe we should consider renaming interrupts.S, after all... ;-) >> > > Sure, I'm not married to the name, think I was inspired by some other arch > back in the days. > > We can call it world-switch.S > > Bah, not something I'd worry about yet. > ok, patch (new version from your tree) applied, thanks! -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
