Re: HVM CPU enumeration, mapping to VCPU ID (Was: Re: [Xen-users] FreeBSD PVHVM call for testing)

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Jun 05, 2013 at 09:15:41AM -0700, Matt Wilson wrote:
> On Tue, Jun 04, 2013 at 10:22:24AM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > > The new hypercall to figure this out could be used, but that wouldn't
> > > > > > explain why we are failing to start on the correct VCPU?
> > > > > 
> > > > > I didn't follow the jump here. Can you provide an example?
> > > > 
> > > > http://lists.xen.org/archives/html/xen-devel/2013-05/msg00941.html
> > > 
> > > OK, got it.
> > > 
> > > [   84.619508] smpboot: Booting Node 0 Processor 1 APIC 0x8
> > > 
> > > So it seems like, in this case:
> > > 
> > > int __cpuinit native_cpu_up(unsigned int cpu)
> > > {
> > >         int apicid = apic->cpu_present_to_apicid(cpu);
> > > 
> > > apic->cpu_present_to_apicid(1) returned 8 instead of 2.
> > > 
> > > All of that should have been set up correctly ahead of time by
> > > generic_processor_info() for all possible CPUs. Do you have the full
> > > boot log?
> > > 
> 
> [...]
> 
> > [    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> > [    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] disabled)
> > [    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
> > [    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
> > [    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
> > [    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
> [...]
> > [    0.000000] ACPI: LAPIC (acpi_id[0x7b] lapic_id[0xf6] disabled)
> > [    0.000000] ACPI: LAPIC (acpi_id[0x7c] lapic_id[0xf8] disabled)
> > [    0.000000] ACPI: LAPIC (acpi_id[0x7d] lapic_id[0xfa] disabled)
> > [    0.000000] ACPI: LAPIC (acpi_id[0x7e] lapic_id[0xfc] disabled)
> > [    0.000000] ACPI: LAPIC (acpi_id[0x7f] lapic_id[0xfe] disabled)
> 
> OK, so generic_processor_info() is not called for disabled processors,
> so it must happen at processor UP time.
> 
> Can you boot with "acpi.debug_layer=0x20000000 acpi.debug_level=0x4"?

If I can reproduce it again - absolutly. Right now the race seems to have
gone away and the APIC id is 0x02 (the right value) instead of 0x08.