diff options
author | Vitaly Kuznetsov <vkuznets@redhat.com> | 2016-09-08 11:48:28 +0200 |
---|---|---|
committer | David Vrabel <david.vrabel@citrix.com> | 2016-09-14 14:39:13 +0100 |
commit | de75abbe0121a6c3c9c6b04c75300088e57ad1d5 (patch) | |
tree | def35bbb8678c3d1820fd730d73ae440c753057b /arch/arm/kvm/mmu.c | |
parent | 55467dea2967259f21f4f854fc99d39cc5fea60e (diff) | |
download | linux-de75abbe0121a6c3c9c6b04c75300088e57ad1d5.tar.bz2 |
arm/xen: fix SMP guests boot
Commit 88e957d6e47f ("xen: introduce xen_vcpu_id mapping") broke SMP
ARM guests on Xen. When FIFO-based event channels are in use (this is
the default), evtchn_fifo_alloc_control_block() is called on
CPU_UP_PREPARE event and this happens before we set up xen_vcpu_id
mapping in xen_starting_cpu. Temporary fix the issue by setting direct
Linux CPU id <-> Xen vCPU id mapping for all possible CPUs at boot. We
don't currently support kexec/kdump on Xen/ARM so these ids always
match.
In future, we have several ways to solve the issue, e.g.:
- Eliminate all hypercalls from CPU_UP_PREPARE, do them from the
starting CPU. This can probably be done for both x86 and ARM and, if
done, will allow us to get Xen's idea of vCPU id from CPUID/MPIDR on
the starting CPU directly, no messing with ACPI/device tree
required.
- Save vCPU id information from ACPI/device tree on ARM and use it to
initialize xen_vcpu_id mapping. This is the same trick we currently
do on x86.
Reported-by: Julien Grall <julien.grall@arm.com>
Tested-by: Wei Chen <Wei.Chen@arm.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Diffstat (limited to 'arch/arm/kvm/mmu.c')
0 files changed, 0 insertions, 0 deletions