RE: [Xen-devel] [PATCH] use per-cpu variables in cpufreq

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Tian, Kevin wrote:
>> From: Keir Fraser
>> Sent: Monday, May 30, 2011 5:45 PM
>> 
>> On 30/05/2011 06:47, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx>
>> wrote: 
>> 
>>>> Specifically, my fear is that this data gets pushed into the
>>>> hypervisor once-only during dom0 boot (via
>>>> XENPF_set_processor_pminfo). If it is freed during processor
>>>> offline, we lose it forever and have no power management when/if a
>>>> CPU is brought back online. Worse I suspect your patch as it is
>>>> will crash if some CPUs are offline during boot as you'll
>>>> deference their per_cpu area which doesn't actually exist unless a
>>>> CPU is online. You can test this for yourself by adding a
>>>> maxcpus=1 boot parameter for Xen.  
>>> 
>>> Indeed.
>>> 
>>> Just to understand this completely:
>>> So when is this info set up for hot-plugged cpus? And what happens
>>> if 
>>> a cpu module is removed and later replaced by another module with
>>> more cores (or threads) than the original one?
>>> I think the processor pminfo should be set in this case during the
>>> hotplug handling.
>> 
>> Well, there is a difference between logical and physical cpu
>> hotplug. Xen is capable of bringing CPUs online and offline without
>> them actually being physically plugged/unplugged from the mainboard.
>> Indeed our physical hotplug support is relatively new and I would
>> suspect not much used (and it supports only physical insertion, not
>> removal!). 
>> 
>> Frankly there are a number of questions around CPUs that are
>>  physically plugged in after boot: * How does per-CPU ACPI state
>> like PM info get set up? 
> 
> A hotplug-able cpu still has an ACPI CPU object in DSDT table, which
> may exist in original DSDT table, or dynamically loaded later upon
> hotplug event. Once dom0 ACPI recognizes a new CPU object, it will
> notify Xen about discovered 
> pm information.

Yes. When cpu hotplug, a sci will triggerred dom0 ospm which will then evaluate 
sci, and then call related acpi control method;
control method will again notify() dom0 ospm which cpu what happened.
dom0 got the notifier depend on the way acpi difine cpu as \_SB or \_PR object, 
then continue hypercall hypervisor ...

Thanks,
Jinsong

> 
>>  * In a system where TSCs are otherwise all perfectly in sync, does
>> the firmware help us by setting up the new CPUs' TSCs likewise?
> 
> Here what firmware can do is similar to what Xen can do, which can't
> ensure you a truly synchronized TSC on new CPU.
> 
> Thanks
> Kevin


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