diff options
| author | Vitaly Kuznetsov <vkuznets@redhat.com> | 2016-06-30 17:56:37 +0200 |
|---|---|---|
| committer | David Vrabel <david.vrabel@citrix.com> | 2016-07-25 14:31:16 +0200 |
| commit | 88e957d6e47f1232ad15b21e54a44f1147ea8c1b (patch) | |
| tree | e7384643d570bd17463455d26fc63ada4ecf24a4 /include/xen | |
| parent | x86/acpi: store ACPI ids from MADT for future usage (diff) | |
| download | linux-88e957d6e47f1232ad15b21e54a44f1147ea8c1b.tar.xz 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 'include/xen')
| -rw-r--r-- | include/xen/xen-ops.h | 6 |
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); |