RE: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
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>
>>>> 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.
>>> Just to understand this completely:
>>> So when is this info set up for hot-plugged cpus? And what happens
>>> 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
>> 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 ...
>> * 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.
Xen-devel mailing list