[PATCH] ARM: KVM: iterate over all CPUs for CPU compatibility check
Andre Przywara
andre.przywara at linaro.org
Mon Apr 15 05:39:28 EDT 2013
On 04/15/2013 11:14 AM, Peter Maydell wrote:
> On 15 April 2013 09:54, Christoffer Dall <cdall at cs.columbia.edu> wrote:
>> On Mon, Apr 15, 2013 at 1:43 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> As for the affinity, we can enforce this very easily.
>>>
>> OK, but let's not go down this road until we've verified that this is
>> really an issue that needs to be handled by excluding A7s. Andre, can
>> you give us some more details?
Sure, I am about to collect some data.
>
> We *must* exclude KVM vcpu threads from ever running on A7s,
> because the cp15 handling code as it stands does not virtualize
> various registers (most notably the ID/feature registers) and
> so the vcpu will bounce between "looks like an A15" and "looks
> like a weird hybrid between A7 and A15".
Can't we propagate some least common denominator or safe values for
those registers instead of propagating the host ones? Or ignore writes
to them? Or are there any real showstoppers which I overlooked? Things
like cache architecture properties could just be set to some basic
values, right?
On x86 propagating too much of host CPU information has proven to be
problematic, so for instance cache info is very generic. Things are more
complicated here, because CPUID is (guest) userland accessible.
Eventually the user/qemu should be able to override this, but as a
default and for now we should inject one fixed handcrafted CPU
regardless of the actual host CPU. If A7 is easier in this regards, this
should be considered, too.
> Assuming we don't want to tackle full big.LITTLE host support
> right now, I can see two options:
> * forbid KVM completely on a system with any non-A15s
> * force KVM vcpus to only ever run on the A15s
I thought a bit about this. It is not so easy to accomplish in a sane
way. The CPU is chosen by the scheduler, actually for the QEMU thread.
taskset could be of use here, but the affinity could be changed at any
time by userland. I thought about returning -EINVAL for the KVM_RUN
ioctl if the CPU is not appropriate, but a) QEMU does not know how to
handle this properly and b) kvm_arch_vcpu_load currently returns void,
so we would need to change it for all KVM architectures.
Not sure if its worth to establish this until we fix bL support properly.
> [Q: does
> all the hyp mode code have to also run on the A15s or
> is it A7-safe?]
Good point. It seems like the code hangs in init_hyp_mode().
Will do more debugging in there now.
Regards,
Andre.
More information about the linux-arm-kernel
mailing list