[Xen-devel] RE: [PATCH][pvops_dom0][4/4] use physical acpi_id in acpi processor parsing logic

["Yu, Ke" <ke.yu@xxxxxxxxx>]

>From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
>Sent: Tuesday, July 21, 2009 4:36 AM
>To: Yu, Ke
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Tian, Kevin
>Subject: Re: [PATCH][pvops_dom0][4/4] use physical acpi_id in acpi processor
>parsing logic
>
>On 07/18/09 23:46, Yu, Ke wrote:
>> use physical acpi_id in acpi processor parsing logic
>>
>> xen domain0 is seeing vCPU, while xen need the acpi info of physical CPU,
>so this patch hack the acpi processor parsing logic to use physical acpi_id
>instead vcpu id
>>
>
>Would there be a problem with making this always use the acpi id?  That
>would get rid of the Xen-specific stuff, and makes logical sense (at
>least to me) since this code is dealing with APIC processor objects.

>
>I guess this goes back to my earlier comment; could this code be defined
>in terms of ACPI processors rather than general CPUs, so that the Xen
>(or any virtual) case can distinguish the two notions, while they can be
>mapped 1:1 for the native case?  (Or perhaps there are reasons you might
>want to have ACPI control processor power states which are logically
>offline to the kernel?)
>
>    J
>

To use acpi id in native, I can see there are at least two kind of conflicts 
need to be resolved: 
1. kernel assume it only cares about the present CPU. For non present CPU, it 
will simply stop going further and return, or trigger BUG(). When switch to 
acpi id, the acpi processor object may refer to a non present cpu, so the code 
need to be able to handle the non-present CPU situation.
2. native kernel use per_cpu data extensively, which is indexed by general cpu 
id. when switch to acpi id, these per_cpu data should be changed to the array 
indexed by acpi id.

Take the acpi processor core code (driver/acpi/ processor_core.c) as example, 
the condition check " BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0)); " need 
change. the per-cpu data processor_device_array, processors need change. And 
the cpu_sys_devices in get_cpu_sysdev need more thoughts before changing, since 
it is globally used by other component.

Another example is the cpufreq case. if we want to use acpi id in cpufreq case, 
we also need to resolve the above two conflicts. For example, in 
drivers/cpufreq/cpufreq.c, its core data struct " cpufreq_policy " is per-CPU, 
thus need many changes in every place it is used. and the condition checking, 
like " if (cpu >= nr_cpu_ids) goto err_out;" also need change. Compared with 
the change in the driver/acpi/ processor_core.c, the change in cpufreq is more 
intrusive. Since the acpi processor core code already has the Px info parsing 
functionality, it may be better not changing cpufreq.

Best Regards
Ke

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel