On 04/15/2013 03:48 PM, Will Deacon wrote: > On Mon, Apr 15, 2013 at 02:13:55PM +0100, Andre Przywara wrote: >> On 04/15/2013 11:52 AM, Alexander Spyridakis wrote: >>> I've run on this problem before, while trying to run KVM guests on A7 cores. >>> >>> For some reason the 3rd A7 hangs in arch/arm/kvm/init.S, on the >>> instruction that updates HSCTLR between the two isbs on __do_hyp_init >>> (mcr p15, 4, r0, c1, c0, 0). If you boot the system with maxcpus=4 then >>> init_hyp_mode() will not hang on the A7 cluster. Other than that from my >>> limited testing KVM on A7 works on a usual linux guest. I also tried to >>> only boot the 3rd A7 core to rule out any racing issues, but still the >>> same behaviour applies. >> >> Could well be the same issue here. I chased it down till CPU 2 goes into >> HYP mode to do the initialization. >> I am running with maxcpus=3 (this increases the likelyhood that >> kvm_target_cpu() runs on an A15), so CPU #2 is the only one A7. >> As the HYP mode exception table is empty except for the HVC trap, it may >> be looping here. I am trying now to get the PC of the faulty instruction. > > Yes, it sounds like you're taking a recursive fault because the vectors > aren't installed yet. Is there any chance you can find out what value you end > up writing (or trying to write) to the HSCTLR please? Mmh, still thinking about a nice way to get some information out of HYP mode. schedule_delayed_work() to monitor a memory address didn't work (too early?). But meanwhile I compared the A7 and A15 TRM 4.3.32 HSCTLR: Bit 21 is fixed 0 on A15, but fixed 1 on A7. Can someone confirm that this is not a typo? Regards, Andre. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
