aboutsummaryrefslogtreecommitdiff
path: root/linux-user
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw@amazon.co.uk>2022-12-16 11:05:29 +0000
committerDavid Woodhouse <dwmw@amazon.co.uk>2023-03-01 08:22:49 +0000
commit5e691a955a06dc9a45d9ab62769a12e6e8d18cee (patch)
treea66e96a83475c7fec72457df9a288ac0c84b780a /linux-user
parentf66b8a83c5723e5337d522ba2b87bf8c7e306445 (diff)
downloadqemu-5e691a955a06dc9a45d9ab62769a12e6e8d18cee.zip
qemu-5e691a955a06dc9a45d9ab62769a12e6e8d18cee.tar.gz
qemu-5e691a955a06dc9a45d9ab62769a12e6e8d18cee.tar.bz2
i386/kvm: Set Xen vCPU ID in KVM
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>
Diffstat (limited to 'linux-user')
0 files changed, 0 insertions, 0 deletions