Re: Workings/effectiveness of the xen-acpi-processor driver

[Boris Ostrovsky <boris.ostrovsky@amd.com>]

On 05/01/2012 08:47 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, May 01, 2012 at 06:54:56PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Tue, May 01, 2012 at 06:35:45PM -0400, Boris Ostrovsky wrote:
>>> On 05/01/2012 04:02 PM, Konrad Rzeszutek Wilk wrote:
>>>> On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote:
>>>>> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote:
>>>>>> On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote:
>>>>>>> Since there have been requests about that driver to get backported into 3.2, I
>>>>>>> was interested to find out what or how much would be gained by that.
>>>>>>>
>>>>>>> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz). Which
>>>>>>> was not very successful as the drivers bail out of the init function because the
>>>>>>> first call to acpi_processor_register_performance() returns -ENODEV. There is
>>>>>>> some frequency scaling when running without Xen, so I need to do some more
>>>>>>> debugging there.
>>>
>>> I believe this is caused by the somewhat under-enlightened xen_apic_read():
>>>
>>> static u32 xen_apic_read(u32 reg)
>>> {
>>>          return 0;
>>> }
>>>
>>> This results in some data, most importantly
>>> boot_cpu_physical_apicid, not being set correctly and, in turn,
>>> causes x86_cpu_to_apicid to be broken.
>>
>> What is the involvment of x86_cpu_to_apicid to acpi_processor_register_performance?
>> Or is this more of a stab in the dark?
>
> Ah, it is the acpi_get_cpuid that gets called by acpi_processor_add->acpi_processor_get_info.
>
> And this one:
> 201 #ifdef CONFIG_SMP
> 202         for_each_possible_cpu(i) {
> 203                 if (cpu_physical_id(i) == apic_id)
> 204                         return i;
> 205         }
> 206 #else
>
> where the cpu_physical_id(i) is per_cpu(x86_cpu_to_apicid, i).

Right. This and the fact that 'if (apicid == boot_cpu_physical_apicid)' 
in generic_processor_info() is never true.

In the end, 'processors' per-cpu variable is not initialized for cpu 0 
and that's what causes acpi_processor_register_performance() to fail.

>
> But it is curious that it has been working for me on AMD and Intel machines.
> Granted the only server boxes I've are Intel - don't have AMD server boxes at all.

I am also surprised that aside from some power inefficiencies and "BIOS 
bug" warnings the system appeared reasonably OK. I'd think that with 
APIC IDs messed up it would not run.

If Intel processors number cores starting with APICID=0 then you 
wouldn't see any issues.

-boris

>
> Stefan, can you send the full dmesg output too please?
>