From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
Subject: Re: Workings/effectiveness of the xen-acpi-processor
 driver
Date: Thu, 3 May 2012 13:02:50 -0400
Message-ID: <4FA2BA3A.7070100@amd.com>
References: <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> <4FA280DA.9080505@canonical.com>
	<4FA29A92.2040601@canonical.com>
	<20120503154620.GB3464@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20120503154620.GB3464@andromeda.dapyr.net>
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@darnok.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan Beulich <jbeulich@suse.com>, Stefan Bader <stefan.bader@canonical.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
List-Id: xen-devel@lists.xenproject.org

On 05/03/2012 11:46 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, May 03, 2012 at 04:47:46PM +0200, Stefan Bader wrote:
>> On 03.05.2012 14:58, Stefan Bader wrote:
>>
>>>>>>> So this shoudl solve the problem for the bootup processor.
>>>>>>>>
>>>>>>>> -boris
>>>>>>>>
>>>>>>>>
>>>>>>>>> +    };
>>>>>>>>> +    int ret = 0;
>>>>>>>>> +
>>>>>>>>> +    /* Shouldn't need this as APIC is turned off for PV, and we only
>>>>>>>>> +     * get called on the bootup processor. But just in case. */
>>>>>>>>> +    if (!xen_initial_domain() || smp_processor_id())
>>>>>>>>> +        return 0;
>>>>>>>>> +
>>>>>>>>> +    if (reg == APIC_LVR)
>>>>>>>>> +        return 0x10;
>>>>>>>>> +
>>>>>>>>> +    if (reg != APIC_ID)
>>>>>>>>> +        return 0;
>>>>>>>>> +
>>>>>>>>> +    ret = HYPERVISOR_dom0_op(&op);
>>>>>>>>> +    if (ret)
>>>>>>>>> +        return 0;
>>>>>>>>> +
>>>>>>>>> +    return op.u.pcpu_info.apic_id;


	return (op.u.pcpu_info.apic_id << 24);

indeed fixes the problem.

-boris


>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>>    static void xen_apic_write(u32 reg, u32 val)
>>>
>>> I added debugging to all exit paths that could return 0 (which is what the
>>> boot_cpu_physical_apicid is set to with that patch. Which would only leave the
>>> case of the HV call returning the wrong value somehow...
>>>
>> Hmmm, so xen_apic_read is still correct...
>>
>> [    0.000000] ACPI: Local APIC address 0xfee00000
>> [    0.000000] xxx xen_apic_read(20)
>> [    0.000000] xxx xen_apic_read ->  10
>> [    0.000000] boot_cpu_physical_apicid = 0
>> [    0.000000] xxx xen_apic_read(30)
>> [    0.000000] +- apic version = 10
>>
>> there seems to be a slightly strange tweak (at least for me) in read_apic_id...
>>
>> static inline unsigned int read_apic_id(void)
>> {
>>          unsigned int reg;
>>
>>          reg = apic_read(APIC_ID); // calls apic->read(reg)
>>
>>          return apic->get_apic_id(reg);
>
> Duh!! Let me spin out a new patch that will do this.
>> }
>>
>>
>
>
>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>