[PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility check

[marc.zyngier@arm.com (Marc Zyngier)]

On Mon, 22 Apr 2013 12:02:59 +0100, Marc Zyngier <marc.zyngier@arm.com>
wrote:
> 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@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

Actually you, may want to try:
SCC: 0x400 0x3330c00

instead, as Peter pointed out that some bits are flagged as reserved in
the TRM...

        M.

-- 
Fast, cheap, reliable. Pick two.