mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-08-03 07:43:54 -06:00
5e691a955a
There are (at least) three different vCPU ID number spaces. One is the internal KVM vCPU index, based purely on which vCPU was chronologically created in the kernel first. If userspace threads are all spawned and create their KVM vCPUs in essentially random order, then the KVM indices are basically random too. The second number space is the APIC ID space, which is consistent and useful for referencing vCPUs. MSIs will specify the target vCPU using the APIC ID, for example, and the KVM Xen APIs also take an APIC ID from userspace whenever a vCPU needs to be specified (as opposed to just using the appropriate vCPU fd). The third number space is not normally relevant to the kernel, and is the ACPI/MADT/Xen CPU number which corresponds to cs->cpu_index. But Xen timer hypercalls use it, and Xen timer hypercalls *really* want to be accelerated in the kernel rather than handled in userspace, so the kernel needs to be told. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
86 lines
2.5 KiB
C
86 lines
2.5 KiB
C
/*
|
|
* Xen HVM emulation support in KVM
|
|
*
|
|
* Copyright © 2019 Oracle and/or its affiliates. All rights reserved.
|
|
* Copyright © 2022 Amazon.com, Inc. or its affiliates. All Rights Reserved.
|
|
*
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
* See the COPYING file in the top-level directory.
|
|
*
|
|
*/
|
|
|
|
#include "qemu/osdep.h"
|
|
#include "sysemu/kvm_int.h"
|
|
#include "sysemu/kvm_xen.h"
|
|
#include "kvm/kvm_i386.h"
|
|
#include "xen-emu.h"
|
|
|
|
int kvm_xen_init(KVMState *s, uint32_t hypercall_msr)
|
|
{
|
|
const int required_caps = KVM_XEN_HVM_CONFIG_HYPERCALL_MSR |
|
|
KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL | KVM_XEN_HVM_CONFIG_SHARED_INFO;
|
|
struct kvm_xen_hvm_config cfg = {
|
|
.msr = hypercall_msr,
|
|
.flags = KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL,
|
|
};
|
|
int xen_caps, ret;
|
|
|
|
xen_caps = kvm_check_extension(s, KVM_CAP_XEN_HVM);
|
|
if (required_caps & ~xen_caps) {
|
|
error_report("kvm: Xen HVM guest support not present or insufficient");
|
|
return -ENOSYS;
|
|
}
|
|
|
|
if (xen_caps & KVM_XEN_HVM_CONFIG_EVTCHN_SEND) {
|
|
struct kvm_xen_hvm_attr ha = {
|
|
.type = KVM_XEN_ATTR_TYPE_XEN_VERSION,
|
|
.u.xen_version = s->xen_version,
|
|
};
|
|
(void)kvm_vm_ioctl(s, KVM_XEN_HVM_SET_ATTR, &ha);
|
|
|
|
cfg.flags |= KVM_XEN_HVM_CONFIG_EVTCHN_SEND;
|
|
}
|
|
|
|
ret = kvm_vm_ioctl(s, KVM_XEN_HVM_CONFIG, &cfg);
|
|
if (ret < 0) {
|
|
error_report("kvm: Failed to enable Xen HVM support: %s",
|
|
strerror(-ret));
|
|
return ret;
|
|
}
|
|
|
|
s->xen_caps = xen_caps;
|
|
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;
|
|
}
|