Re: [PATCH v7 04/10] tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves

["Alejandro Vallejo" <alejandro.vallejo@xxxxxxxxx>]

On Wed Oct 30, 2024 at 11:31 AM GMT, Andrew Cooper wrote:
> On 21/10/2024 4:45 pm, Alejandro Vallejo wrote:
> > diff --git a/tools/firmware/hvmloader/config.h 
> > b/tools/firmware/hvmloader/config.h
> > index cd716bf39245..04cab1e59f08 100644
> > --- a/tools/firmware/hvmloader/config.h
> > +++ b/tools/firmware/hvmloader/config.h
> > @@ -4,6 +4,8 @@
> >  #include <stdint.h>
> >  #include <stdbool.h>
> >  
> > +#include <xen/hvm/hvm_info_table.h>
> > +
> >  enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
> >  extern enum virtual_vga virtual_vga;
> >  
> > @@ -48,8 +50,9 @@ extern uint8_t ioapic_version;
> >  
> >  #define IOAPIC_ID           0x01
> >  
> > +extern uint32_t cpu_to_x2apicid[HVM_MAX_VCPUS];
>
> Just cpu_to_apic_id[] please.   The distinction between x or x2 isn't
> interesting here.

I disagree.

While "x" says nothing of interest "x2" does state the width. cpu_to_apic_id is
ambiguous and I've seen no shortage of code in which it's impossible to assess
its correctness without going to check what the original author meant; and
guesswork is bad for robustness. cpu_to_x2apicid has an unambiguous width at
the meager cost of 2 chars. If you have very strong feelings about it I can
change it, but my preference is to keep it as-is.

>
> HVM_MAX_VCPUS is a constant that should never have existed in the first
> place, *and* its the limit we're looking to finally break when this
> series is accepted.
>
> This array needs to be hvm_info->nr_vcpus entries long, and will want to
> be more than 128 entries very soon.  Just scratch_alloc() the array. 
> Then you can avoid the include.

That's a major PITA in the libxl side. I'll have a go to see how long it takes
me before I weep :_)

>
> > diff --git a/tools/firmware/hvmloader/mp_tables.c 
> > b/tools/firmware/hvmloader/mp_tables.c
> > index 77d3010406d0..539260365e1e 100644
> > --- a/tools/firmware/hvmloader/mp_tables.c
> > +++ b/tools/firmware/hvmloader/mp_tables.c
> > @@ -198,8 +198,10 @@ static void fill_mp_config_table(struct 
> > mp_config_table *mpct, int length)
> >  /* fills in an MP processor entry for VCPU 'vcpu_id' */
> >  static void fill_mp_proc_entry(struct mp_proc_entry *mppe, int vcpu_id)
> >  {
> > +    ASSERT(cpu_to_x2apicid[vcpu_id] < 0xFF );
>
> This is just going to break when we hit 256 vCPUs in a VM.
>
> What do real systems do?
>
> They'll either wrap around 255 like the CPUID xAPIC_ID does, or they'll
> not write out MP tables at all.

Definitely not wrapping around, that makes no sense.

It could also show the first 255 APs only. The reality is that if we're
exposing 1000 vCPUs is because we expect the guest to use them. While it's
likely we want to avoid writing the MP tables, that's not a puddle I want to
play with ATM.

Note that this is not a new breakage. It was already broken if we were to hit
such an APIC ID (which we can't because HVM_MAX_VCPUS is lower). I just made
sure we never write out corrupted tables.

>
> > diff --git a/tools/firmware/hvmloader/smp.c b/tools/firmware/hvmloader/smp.c
> > index 1b940cefd071..d63536f14f00 100644
> > --- a/tools/firmware/hvmloader/smp.c
> > +++ b/tools/firmware/hvmloader/smp.c
> > @@ -90,10 +120,11 @@ static void boot_cpu(unsigned int cpu)
> >          BUG();
> >  
> >      /*
> > -     * Wait for the secondary processor to complete initialisation.
> > +     * Wait for the secondary processor to complete initialisation,
> > +     * which is signaled by its x2APIC ID being written to the LUT.
>
> Technically all arrays are a lookup table, but I'm not sure LUT is a

No. A look-up table is a very specific implementation of a relation (in the
mathematical sense) between an unsigned integer and some other type,
implemented by means of an array indexed by said integer.

> common enough term to be used unqualified like this.

Happy to change the name if it's uncommon enough in this codebase, but it is
fairly common outside of it, and it's common enough to have its own wikipedia
page with that very acronym.

  https://en.wikipedia.org/wiki/Lookup_table

>
> Just say "... signalled by writing its APIC_ID out."  The where is very
> apparent by the code.
>
> > @@ -104,6 +135,12 @@ static void boot_cpu(unsigned int cpu)
> >  void smp_initialise(void)
> >  {
> >      unsigned int i, nr_cpus = hvm_info->nr_vcpus;
> > +    uint32_t ecx;
> > +
> > +    cpuid(1, NULL, NULL, &ecx, NULL);
> > +    has_x2apic = (ecx >> 21) & 1;
> > +    if ( has_x2apic )
> > +        printf("x2APIC supported\n");
>
> You need to check max_leaf >= 0xb too.  Remember Xen might not give you
> leave 0xb yet, and then you'll hit the assert for finding 0.

True.

>
> And has_x2apic wants to be a simple boolean.  Nothing good can come from
> confusing -1 with "x2apic available".

Sure

>
>
> I recommend splitting this patch into three.  Several aspects are quite
> subtle.
>
> 1) Collect the APIC_IDs on APs
> 2) Change how callin is signalled.
> 3) Replace LAPIC_ID() with the collected apic_id.
>
> but AFAICT, it can be done as a standalone series, independently of the
> other Xen/toolstack work.

Ack

>
> ~Andrew

Cheers,
Alejandro