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

[Christoffer Dall]

On Tue, Apr 16, 2013 at 11:37 AM, Alexander Spyridakis
<a.spyridakis at virtualopensystems.com> wrote:
> On 16 April 2013 17:59, Christoffer Dall <cdall at cs.columbia.edu> wrote:
>> On Mon, Apr 15, 2013 at 2:52 AM, Alexander Spyridakis
>> <a.spyridakis at virtualopensystems.com> 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.
>>>
>> You lost me on the maxcpus=4 and racing point here. If it works with
>> maxcpus=4 then it works with two A7s, right? Why would running with
>> maxcpus=3 (ie. one A7) rule out any race condition?
>
> maxcpus=3 would still work (only one A7), but I didn't test it that
> way. To make sure and avoid any race conditions from other cpus, I
> changed the bootwrapper to explicitly boot only the 3rd A7 (rest of
> the cpus being in an infinite loop) and it would still hang. Booting
> only the 1st or 2nd A7 core by the same method would work as expected
> (no hang in __do_hyp_init_).
>
so work as expected, as in it doesn't work... Hence the confusion.

I don't think this is racy in any way, but for the record, you still
have a couple of other A15s running here, so you can't completely rule
out races based on your experimental approach, but I really don't
think that's the issue anyhow.