diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index aac43174e8..edcf8a2a65 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -1884,6 +1884,11 @@ int kvm_arch_init_vcpu(CPUState *cs) } } + r = kvm_xen_init_vcpu(cs); + if (r) { + return r; + } + kvm_base += 0x100; #else /* CONFIG_XEN_EMU */ /* This should never happen as kvm_arch_init() would have died first. */ diff --git a/target/i386/kvm/xen-emu.c b/target/i386/kvm/xen-emu.c index 34d5bc1bc9..4883b95d9d 100644 --- a/target/i386/kvm/xen-emu.c +++ b/target/i386/kvm/xen-emu.c @@ -52,6 +52,34 @@ int kvm_xen_init(KVMState *s, uint32_t hypercall_msr) return 0; } +int kvm_xen_init_vcpu(CPUState *cs) +{ + int err; + + /* + * The kernel needs to know the Xen/ACPI vCPU ID because that's + * what the guest uses in hypercalls such as timers. It doesn't + * match the APIC ID which is generally used for talking to the + * kernel about vCPUs. And if vCPU threads race with creating + * their KVM vCPUs out of order, it doesn't necessarily match + * with the kernel's internal vCPU indices either. + */ + if (kvm_xen_has_cap(EVTCHN_SEND)) { + struct kvm_xen_vcpu_attr va = { + .type = KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID, + .u.vcpu_id = cs->cpu_index, + }; + err = kvm_vcpu_ioctl(cs, KVM_XEN_VCPU_SET_ATTR, &va); + if (err) { + error_report("kvm: Failed to set Xen vCPU ID attribute: %s", + strerror(-err)); + return err; + } + } + + return 0; +} + uint32_t kvm_xen_get_caps(void) { return kvm_state->xen_caps; diff --git a/target/i386/kvm/xen-emu.h b/target/i386/kvm/xen-emu.h index 2101df0182..d62f1d8ed8 100644 --- a/target/i386/kvm/xen-emu.h +++ b/target/i386/kvm/xen-emu.h @@ -24,5 +24,6 @@ #define XEN_VERSION(maj, min) ((maj) << 16 | (min)) int kvm_xen_init(KVMState *s, uint32_t hypercall_msr); +int kvm_xen_init_vcpu(CPUState *cs); #endif /* QEMU_I386_KVM_XEN_EMU_H */