WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] c/s 18470

To: "Jinsong Liu" <jinsong.liu@xxxxxxxxx>
Subject: Re: [Xen-devel] c/s 18470
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 17 Sep 2008 11:45:59 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 17 Sep 2008 03:45:44 -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
>>> "Jan Beulich" <jbeulich@xxxxxxxxxx> 17.09.08 09:43 >>>
>This changeset reverts two previous corrections, for reasons that escape
>me.
>
>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?

Also, were these changes tested on AMD CPUs? It would seem to me
that the cpufreq_cpu_policy array would remain uninitialized here, and
hence the first access in the powernow code would dereference a NULL
pointer.

Likewise the calls to cpufreq_{add,del}_cpu() from the CPU hot(un)plug
paths seem to consider the Intel case only (as the functions themselves
are Intel specific).

Jan


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

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