From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: Workings/effectiveness of the xen-acpi-processor
 driver
Date: Thu, 3 May 2012 12:14:09 -0400
Message-ID: <20120503161409.GB9992@phenom.dumpdata.com>
References: <4F9976F8.8040502@canonical.com>
	<20120501200207.GA15313@phenom.dumpdata.com>
	<4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com>
	<20120502160812.GA6611@phenom.dumpdata.com>
	<4FA1699A.9070405@amd.com>
	<20120502171415.GA17477@phenom.dumpdata.com>
	<4FA1A79B.5040701@amd.com>
	<20120502214147.GA7670@phenom.dumpdata.com>
	<4FA1B096.5010009@amd.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: <4FA1B096.5010009@amd.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: Boris Ostrovsky <boris.ostrovsky@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan Beulich <jbeulich@suse.com>, Stefan Bader <stefan.bader@canonical.com>
List-Id: xen-devel@lists.xenproject.org

On Wed, May 02, 2012 at 06:09:26PM -0400, Boris Ostrovsky wrote:
> On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote:
> >>On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote:
> >>>On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote:
> >>>>On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >>>>>index a8f8844..d816448 100644
> >>>>>--- a/arch/x86/xen/enlighten.c
> >>>>>+++ b/arch/x86/xen/enlighten.c
> >>>>>@@ -811,7 +811,29 @@ static void xen_io_delay(void)
> >>>>>  #ifdef CONFIG_X86_LOCAL_APIC
> >>>>>  static u32 xen_apic_read(u32 reg)
> >>>>>  {
> >>>>>-	return 0;
> >>>>>+	struct xen_platform_op op = {
> >>>>>+		.cmd = XENPF_get_cpuinfo,
> >>>>>+		.interface_version = XENPF_INTERFACE_VERSION,
> >>>>>+		.u.pcpu_info.xen_cpuid = 0,
> >>>>
> >>>>
> >>>>Is this always zero? This will probably solve the current problem
> >>>
> >>>Its a CPU number (not tied in to APIC or ACPI IDs).
> >>
> >>Why not use CPU number instead of zero here?
> >
> >The issue was only with the bootup CPU - so was using the Xen's
> >bootup CPU number - which is zero (as is Linux's).
> 
> I agree that for this particular problem this may be sufficient.
> 
> My concern is that in the future someone may decide to use
> apic_read(APIC_ID) or read_apic_id() for some other purpose and they
> won't get expected result (i.e. on all CPUs they will get the same
> answer).

Good point. Let's get this particular bug fixed for v3.5, and then will
do a more comprehensive fix for v3.6.