[PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility check
Marc Zyngier
marc.zyngier at arm.com
Mon Apr 22 07:02:59 EDT 2013
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
>> <andre.przywara at linaro.org> 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...
More information about the linux-arm-kernel
mailing list