On Fri, Mar 28, 2014 at 08:57:15PM -0400, Michael Casadevall wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 03/28/2014 08:17 PM, Christoffer Dall wrote: > > On Fri, Mar 28, 2014 at 07:17:49PM -0400, Michael Casadevall > > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> > >> > >> > >> On 03/28/2014 05:29 PM, Christoffer Dall wrote: > >>> On Fri, Mar 28, 2014 at 05:08:03PM -0400, Michael Casadevall > >>> wrote: > >> > >>> if you run the interrupt handler you are not stuck in wfi, but > >>> re-execute it, and it's your software wait condition which is > >>> the problem - likely related to the missing rtc? > >>> > >> > >> The pc returns to the wfi instruction after executing the > >> interrupt handler; this is in a bit of assembly, and not in C > >> code. > > > > It shouldn't. It should return to the instruction after the wfi > > instruction. > > > > Which is why I think there's a bug somewhere :-) This was what I was > banging my head on at LC until I commented it out. Obviously thats not > the correct thing to do, but I'm unsure if this is KVM or EFI doing > something it shouldn't. As I said, I'm not convinced the GIC driver in > EFI is 100% correct.
If your exception return is directly to the WFI instruction (and it's not because you do another iteration of the loop), then it sounds like the exception handler in UEFI is written incorrectly. KVM should not be involved at all in an RFE from EL0 to EL1. Also reading the virtual counter happens directly without trapping, so I would be equally surprised there. Sounds to me like you need to trace the execution of UEFI exactly and figure out what it's doing. If you can write up a guide on how to reproduce your results and where to look in the UEFI code, then I can try taking a look. (Writing such a guide may be needed and useful in any case). -Christoffer _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
