This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Keir Fraser <keir.xen@xxxxxxxxx>, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
From: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
Date: Tue, 31 May 2011 15:37:01 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "mark.langsdorf@xxxxxxx" <mark.langsdorf@xxxxxxx>
Delivery-date: Tue, 31 May 2011 09:19:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <625BA99ED14B2D499DC4E29D8138F1505CA61C06B3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4DE32F6A.7030608@xxxxxxxxxxxxxx> <CA0925C9.1B498%keir.xen@xxxxxxxxx> <625BA99ED14B2D499DC4E29D8138F1505CA61C06B3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acwerk9F8e7j0dGkgkWeWO/HHFUIHQAhiunAAAwLkkA=
Thread-topic: [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>
>> 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 ...


>>  * 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