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: Keir Fraser <keir.xen@xxxxxxxxx>, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 31 May 2011 09:51:26 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "mark.langsdorf@xxxxxxx" <mark.langsdorf@xxxxxxx>
Delivery-date: Tue, 31 May 2011 09:18:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA0925C9.1B498%keir.xen@xxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acwerk9F8e7j0dGkgkWeWO/HHFUIHQAhiunA
Thread-topic: [Xen-devel] [PATCH] use per-cpu variables in cpufreq
> 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.

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