Re: [PATCH 1/1] x86: centralize default APIC id definition

[Juergen Gross <jgross@xxxxxxxx>]

On 01.10.21 16:29, Andrew Cooper wrote:
> On 01/10/2021 15:19, Jan Beulich wrote:
> > On 24.09.2021 21:39, Alex Olson wrote:
> > > Inspired by an earlier attempt by Chao Gao <chao.gao@xxxxxxxxx>,
> > > this revision aims to put the hypervisor in control of x86 APIC identifier
> > > definition instead of hard-coding a formula in multiple places
> > > (libxl, hvmloader, hypervisor).
> > >
> > > This is intended as a first step toward exposing/altering CPU topology
> > > seen by guests.
> > >
> > > Changes:
> > >
> > > - Add field to vlapic for holding default ID (on reset)
> > >
> > > - add HVMOP_get_vcpu_topology_id hypercall so libxl (for PVH domains)
> > >    can access APIC ids needed for ACPI table definition prior to domain start.
> > >
> > > - For HVM guests, hvmloader now also uses the same hypercall.
> > >
> > > - Make CPUID code use vlapic ID instead of hard-coded formula
> > >    for runtime reporting to guests
> > I'm afraid a primary question from back at the time remains: How is
> > migration of a guest from an old hypervisor to one with this change
> > in place going to work?
> I'm afraid its not.
>
> Fixing this is incredibly complicated.  I have a vague plan, but it
> needs building on the still-pending libxl cpuid work of Rogers.
>
> Both the toolstack and Xen need to learn about how to describe topology
> correctly (and I'm afraid this patch isn't correct even for a number of
> the simple cases), and know about "every VM booted up until this point
> in time" being wrong.
What about:

- adding APIC-Id to the migration stream
- adding an optional translation layer for guest APIC-Id to the
  hypervisor
- adding the functionality to set a specific APIC-Id for a vcpu
  (will use the translation layer if not the same as preferred
  by the hypervisor)


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature