v2 -> v3:
(v2/patch2 and v2/patch4 are already committed)
* Moved the vlapic check hook addition to v3/patch1
* And created a check hook for the architectural state too for consistency.
* Fixed migrations from Xen <= 4.13 by reconstructing the previous topology.
* Correctly set the APIC ID after a policy change when vlapic is already in
x2APIC mode.
* Removed bogus assumption introduced in v1 and v2 on hvmloader about which
8bit APIC IDs represent ids > 254. (it's "id % 0xff", not "min(id, 0xff)".
* Used an x2apic flag check instead.
* Various formatting adjustments.
v1 -> v2:
* v1/patch 4 replaced by a different strategy (See patches 4 and 5 in v2):
* Have hvmloader populate MADT with the real APIC IDs as read by the APs
themselves rather than giving it knowledge on how to derive them.
* Removed patches 2 and 3 in v1, as no longer relevant.
* Split v1/patch6 in two parts ((a) creating the generator and (b) plugging it
in) and use the generator in the unit tests of the vcpuid->apicid mapping
function. Becomes patches 6 and 8 in v2.
Patch 1: Same as v1/patch1.
Patch 2: Header dependency cleanup in preparation for patch3.
Patch 3: Adds vlapic_hidden check for the newly introduced reserved area.
Patch 4: [hvmloader] Replaces INIT+SIPI+SIPI sequences with hypercalls.
Patch 5: [hvmloader] Retrieve the per-CPU APIC IDs from the APs themselves.
Patch 6: Split from v1/patch6.
Patch 7: Logically matching v1/patch5, but using v2/patch6 for testing.
Patch 8: Split from v1/patch6.
=== Original cover letter ===
Current topology handling is close to non-existent. As things stand, APIC
IDs are allocated through the apic_id=vcpu_id*2 relation without giving any
hints to the OS on how to parse the x2APIC ID of a given CPU and assuming
the guest will assume 2 threads per core.
This series involves bringing x2APIC IDs into the migration stream, so
older guests keep operating as they used to and enhancing Xen+toolstack so
new guests get topology information consistent with their x2APIC IDs. As a
side effect of this, x2APIC IDs are now packed and don't have (unless under
a pathological case) gaps.
Further work ought to allow combining this topology configurations with
gang-scheduling of guest hyperthreads into affine physical hyperthreads.
For the time being it purposefully keeps the configuration of "1 socket" +
"1 thread per core" + "1 core per vCPU".
Patch 1: Includes x2APIC IDs in the migration stream. This allows Xen to
reconstruct the right x2APIC IDs on migrated-in guests, and
future-proofs itself in the face of x2APIC ID derivation changes.
Patch 2: Minor refactor to expose xc_cpu_policy in libxl
Patch 3: Refactors xen/lib/x86 to work on non-Xen freestanding environments
(e.g: hvmloader)
Patch 4: Remove old assumptions about vcpu_id<->apic_id relationship in
hvmloader
Patch 5: Add logic to derive x2APIC IDs given a CPU policy and vCPU IDs
Patch 6: Includes a simple topology generator for toolstack so new guests
have topologically consistent information in CPUID
Alejandro Vallejo (6):
x86/vlapic: Move lapic migration checks to the check hooks
xen/x86: Add initial x2APIC ID to the per-vLAPIC save area
tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves
xen/lib: Add topology generator for x86
xen/x86: Derive topologically correct x2APIC IDs from the policy
xen/x86: Synthesise domain topologies
tools/firmware/hvmloader/config.h | 6 +-
tools/firmware/hvmloader/hvmloader.c | 4 +-
tools/firmware/hvmloader/smp.c | 54 ++++--
tools/include/xen-tools/common-macros.h | 5 +
tools/libs/guest/xg_cpuid_x86.c | 24 ++-
tools/tests/cpu-policy/test-cpu-policy.c | 201 +++++++++++++++++++++++
xen/arch/x86/cpu-policy.c | 9 +-
xen/arch/x86/cpuid.c | 14 +-
xen/arch/x86/hvm/vlapic.c | 122 ++++++++++----
xen/arch/x86/include/asm/hvm/hvm.h | 2 +
xen/arch/x86/include/asm/hvm/vlapic.h | 2 +
xen/include/public/arch-x86/hvm/save.h | 2 +
xen/include/xen/lib/x86/cpu-policy.h | 27 +++
xen/lib/x86/policy.c | 167 +++++++++++++++++++
xen/lib/x86/private.h | 4 +
15 files changed, 587 insertions(+), 56 deletions(-)
--
2.34.1
