All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Anthony PERARD" <anthony@xenproject.org>,
	"Juergen Gross" <jgross@suse.com>
Subject: [PATCH v2 0/8] x86: Expose consistent topology to guests
Date: Wed,  8 May 2024 13:39:19 +0100	[thread overview]
Message-ID: <cover.1715102098.git.alejandro.vallejo@cloud.com> (raw)

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 (8):
  xen/x86: Add initial x2APIC ID to the per-vLAPIC save area
  xen/x86: Simplify header dependencies in x86/hvm
  x86/vlapic: Move lapic_load_hidden migration checks to the check hook
  tools/hvmloader: Wake APs with hypercalls and not with INIT+SIPI+SIPI
  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           | 151 +++++++++---------
 tools/firmware/hvmloader/util.h          |   5 +
 tools/libs/guest/xg_cpuid_x86.c          |  62 ++------
 tools/tests/cpu-policy/test-cpu-policy.c | 191 +++++++++++++++++++++++
 xen/arch/x86/cpu-policy.c                |   9 +-
 xen/arch/x86/cpuid.c                     |  15 +-
 xen/arch/x86/hvm/irq.c                   |   6 +-
 xen/arch/x86/hvm/vlapic.c                |  75 +++++++--
 xen/arch/x86/include/asm/hvm/hvm.h       |   8 +
 xen/arch/x86/include/asm/hvm/vlapic.h    |   8 +-
 xen/arch/x86/include/asm/hvm/vpt.h       |   1 -
 xen/include/public/arch-x86/hvm/save.h   |   2 +
 xen/include/xen/lib/x86/cpu-policy.h     |  27 ++++
 xen/lib/x86/policy.c                     | 160 +++++++++++++++++++
 16 files changed, 562 insertions(+), 168 deletions(-)

-- 
2.34.1



             reply	other threads:[~2024-05-08 12:39 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-08 12:39 Alejandro Vallejo [this message]
2024-05-08 12:39 ` [PATCH v2 1/8] xen/x86: Add initial x2APIC ID to the per-vLAPIC save area Alejandro Vallejo
2024-05-23 14:32   ` Roger Pau Monné
2024-05-24 10:58     ` Alejandro Vallejo
2024-05-24 11:15       ` Roger Pau Monné
2024-05-08 12:39 ` [PATCH v2 2/8] xen/x86: Simplify header dependencies in x86/hvm Alejandro Vallejo
2024-05-22  9:33   ` Jan Beulich
2024-05-22 15:24     ` Alejandro Vallejo
2024-05-23 14:37   ` Roger Pau Monné
2024-05-23 14:40     ` Jan Beulich
2024-05-23 14:52       ` Roger Pau Monné
2024-05-08 12:39 ` [PATCH v2 3/8] x86/vlapic: Move lapic_load_hidden migration checks to the check hook Alejandro Vallejo
2024-05-23 14:50   ` Roger Pau Monné
2024-05-24 11:16     ` Alejandro Vallejo
2024-05-24 12:53       ` Roger Pau Monné
2024-05-23 18:58   ` Andrew Cooper
2024-05-24  7:22     ` Roger Pau Monné
2024-05-08 12:39 ` [PATCH v2 4/8] tools/hvmloader: Wake APs with hypercalls and not with INIT+SIPI+SIPI Alejandro Vallejo
2024-05-08 19:13   ` Andrew Cooper
2024-05-09 11:04     ` Alejandro Vallejo
2024-05-09 17:50   ` [PATCH 4.5/8] tools/hvmloader: Further simplify SMP setup Andrew Cooper
2024-05-13 17:19     ` Alejandro Vallejo
2024-05-23 15:04     ` Roger Pau Monné
2024-05-08 12:39 ` [PATCH v2 5/8] tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves Alejandro Vallejo
2024-05-23 16:13   ` Roger Pau Monné
2024-05-24 15:16     ` Alejandro Vallejo
2024-05-27  8:55       ` Roger Pau Monné
2024-05-24  7:21   ` Roger Pau Monné
2024-05-24 15:15     ` Alejandro Vallejo
2024-05-27  8:52       ` Roger Pau Monné
2024-05-28 12:35         ` Alejandro Vallejo
2024-05-08 12:39 ` [PATCH v2 6/8] xen/lib: Add topology generator for x86 Alejandro Vallejo
2024-05-23 16:50   ` Roger Pau Monné
2024-05-28 13:28     ` Alejandro Vallejo
2024-05-08 12:39 ` [PATCH v2 7/8] xen/x86: Derive topologically correct x2APIC IDs from the policy Alejandro Vallejo
2024-05-24  8:39   ` Roger Pau Monné
2024-05-24 17:03     ` Alejandro Vallejo
2024-05-27  8:06       ` Roger Pau Monné
2024-05-08 12:39 ` [PATCH v2 8/8] xen/x86: Synthesise domain topologies Alejandro Vallejo
2024-05-24  8:58   ` Roger Pau Monné
2024-05-24 17:16     ` Alejandro Vallejo
2024-05-27  8:20       ` Roger Pau Monné
2024-05-28 14:06         ` Alejandro Vallejo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1715102098.git.alejandro.vallejo@cloud.com \
    --to=alejandro.vallejo@cloud.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.