From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matt Wilson <msw@amazon.com>
Subject: Re: HVM CPU enumeration,
 mapping to VCPU ID (Was: Re: [Xen-users] FreeBSD PVHVM call for
 testing)
Date: Wed, 5 Jun 2013 09:15:41 -0700
Message-ID: <20130605161541.GA10493@u109add4315675089e695.ant.amazon.com>
References: <20130529221036.GB20973@u109add4315675089e695.ant.amazon.com>
	<1369906303.13087.60.camel@zakaz.uk.xensource.com>
	<20130530171634.GD20973@u109add4315675089e695.ant.amazon.com>
	<1369988510.5199.21.camel@zakaz.uk.xensource.com>
	<20130531185320.GA6133@u109add4315675089e695.ant.amazon.com>
	<20130603144443.GA2816@phenom.dumpdata.com>
	<20130603155724.GA737@u109add4315675089e695.ant.amazon.com>
	<20130603173351.GA14348@konrad-lan.dumpdata.com>
	<20130603182258.GA17127@u109add4315675089e695.ant.amazon.com>
	<20130604142224.GC7110@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <20130604142224.GC7110@phenom.dumpdata.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel <xen-devel@lists.xen.org>, Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
List-Id: xen-devel@lists.xenproject.org

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"?

--msw