summaryrefslogtreecommitdiffstats
path: root/include/xen
diff options
context:
space:
mode:
authorVitaly Kuznetsov <vkuznets@redhat.com>2016-06-30 17:56:37 +0200
committerDavid Vrabel <david.vrabel@citrix.com>2016-07-25 13:31:16 +0100
commit88e957d6e47f1232ad15b21e54a44f1147ea8c1b (patch)
treee7384643d570bd17463455d26fc63ada4ecf24a4 /include/xen
parent3e9e57fad3d8530aa30787f861c710f598ddc4e7 (diff)
downloadlinux-stable-88e957d6e47f1232ad15b21e54a44f1147ea8c1b.tar.gz
linux-stable-88e957d6e47f1232ad15b21e54a44f1147ea8c1b.tar.bz2
linux-stable-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 'include/xen')
-rw-r--r--include/xen/xen-ops.h6
1 files changed, 6 insertions, 0 deletions
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 355275bad2cf..c9c532d56623 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -9,6 +9,12 @@
DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);
+DECLARE_PER_CPU(int, xen_vcpu_id);
+static inline int xen_vcpu_nr(int cpu)
+{
+ return per_cpu(xen_vcpu_id, cpu);
+}
+
void xen_arch_pre_suspend(void);
void xen_arch_post_suspend(int suspend_cancelled);