From mboxrd@z Thu Jan 1 00:00:00 1970 From: marc.zyngier@arm.com (Marc Zyngier) Date: Mon, 22 Apr 2013 12:02:59 +0100 Subject: [PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility check In-Reply-To: <517512CA.6070503@linaro.org> References: <51680AF9.7040109@arm.com> <516BCAD0.9000708@linaro.org> <516BFD13.1000400@linaro.org> <20130415134837.GI9827@mudshark.cambridge.arm.com> <32d532438f5b621e40679aea9f5888c7@localhost> <516E586C.5030407@linaro.org> <8e0bda3fd84d1b0c5aa55161ca178a8e@localhost> <51713F91.5080102@linaro.org> <517512CA.6070503@linaro.org> Message-ID: <517518E3.5020209@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 22/04/13 11:36, Andre Przywara wrote: > On 04/19/2013 06:13 PM, Christoffer Dall wrote: >> On Fri, Apr 19, 2013 at 5:58 AM, Andre Przywara >> wrote: >>> On 04/17/2013 11:12 AM, Christoffer Dall wrote: >>>> >>>> ... >>>> >>>> You could also try installing a vector handler early and detect faults, >>>> and add an alternative return path from the init function with some >>>> error reporting value in r0 or something like that, just for debugging, >>>> naturally, but that could be a way to detect if we really are taking >>>> recursive faults here. >>> >>> >>> OK, I added code to return earlier on CPUs not from cluster 0. >>> Indeed it hangs in the HSCR write. The two A15s pass this instruction, >>> writing 0x30c5187F into the register. >>> This means all the fixed bits for A15 correctly, C,A,M and I set and WXN, >>> EE, TE cleared. FI was also cleared >>> The A7 wanted to write the very same value. I tried to set bit 21, which >>> kind of the A7 TRM hints to do: but no change. >>> Before the HSCLTR write, the register reads 0x30c50878, with SCTLR being >>> 0x30c5387d. >>> So the code wants to set M, A, C and I in HSCLTR. Interestingly SCTLR has >>> the V bits set, could that be an issue? >>> >> Can you try writing 0x30c50879 into the register instead? Basically >> check to see if enabling caches or alignment checks causes the issue, >> or if it is indeed enabling the MMU that's the issue... If that works, >> start a bisect on the remaining bits. Also, just for fun, could you >> try flushing the entire I-cache before writing into the HSCLTR? > > OK, both clearing the I-bit and doing an "isb; ICIALLU" before the "isb; > write HSCLTR; isb" worked, the kernel boots on and KVM is enabled. > > I could easily make a patch, but I am not sure how to proceed from here: > > 1.) At least I don't have an understanding why this is only a problem on > A7 and not on A15. I would feel better if we have an explanation for > this. Mark, Will, Peter: any ideas? Blink! Can you check your board.txt config file? It should have a line that starts with "SCC: 0x400 ..." If not, can you add a line that reads: SCC: 0x400 0x00000000 Thanks, M. -- Jazz is not dead. It just smells funny...