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


[Xen-devel] RE: c/s 18470

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: [Xen-devel] RE: c/s 18470
From: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
Date: Thu, 18 Sep 2008 14:37:36 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 17 Sep 2008 23:38:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48D0D138.76E4.0078.0@xxxxxxxxxx>
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: <48D0D138.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckYmPt5dt1sDLo5R5u2wrOZYnM1cgAufSxg
Thread-topic: c/s 18470

For the 1st issue, I notice your patch (c/s 18435), and think it's good
not to limit dom by NR_CPUS. Your change has a precondition that we
already know the max dom number, then alloc dom map according to max dom
number, it's good at our old cpufreq version since at that version,
hypervisor initialize cpufreq dom AFTER we get all px info from dom0 and
hence can get max dom number.
However, recently we update hypervisor cpufreq logic greatly, change
cpufreq init process by per cpu (old version is per dom), in this way we
don't know max dom number and cannot use xmalloc_arry(), so we
temporarily use dom array limit by NR_CPUS, and mark it as TODO that
will update it in later future (i.e. by link list).

For the 2nd issue, our idea is to use flags to separate px init process
from runtime dynamic px handle (like ppc).


-----Original Message-----
From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] 
Sent: Wednesday, September 17, 2008 3:43 PM
To: Liu, Jinsong
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: c/s 18470

This changeset reverts two previous corrections, for reasons that escape

First, the domain map is again being confined to NR_CPUS, which I had
submitted a patch to fix recently (yes, I realize the code has a TODO in
there, but those really get forgotten about far too often).

Second, the platform hypercall was reverted back to require all
information to be passed to Xen in one chunk, whereas I recall that even
Intel folks (not sure if it was you) agreed that allowing incremental
information collection was more appropriate.

Could you clarify why these changes were necessary and if/when you
plan to address the resulting issues?

Thanks, Jan

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>