aboutsummaryrefslogtreecommitdiff
path: root/drivers/xen
diff options
context:
space:
mode:
authorGravatar Vitaly Kuznetsov <vkuznets@redhat.com> 2016-06-30 17:56:37 +0200
committerGravatar David Vrabel <david.vrabel@citrix.com> 2016-07-25 13:31:16 +0100
commit88e957d6e47f1232ad15b21e54a44f1147ea8c1b (patch)
treee7384643d570bd17463455d26fc63ada4ecf24a4 /drivers/xen
parentx86/acpi: store ACPI ids from MADT for future usage (diff)
downloadlinux-88e957d6e47f1232ad15b21e54a44f1147ea8c1b.tar.gz
linux-88e957d6e47f1232ad15b21e54a44f1147ea8c1b.tar.bz2
linux-88e957d6e47f1232ad15b21e54a44f1147ea8c1b.zip
xen: introduce xen_vcpu_id mapping
It may happen that Xen's and Linux's ideas of vCPU id diverge. In particular, when we crash on a secondary vCPU we may want to do kdump and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting on the vCPU which crashed. This doesn't work very well for PVHVM guests as we have a number of hypercalls where we pass vCPU id as a parameter. These hypercalls either fail or do something unexpected. To solve the issue introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct mapping for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary CPUs it is a bit more trickier. Currently, we initialize IPI vectors before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT instead. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Diffstat (limited to 'drivers/xen')
0 files changed, 0 insertions, 0 deletions