From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 8/9] xen/arch/x86: use is_hardware_domain instead of domid == 0 Date: Fri, 12 Apr 2013 17:48:33 +0100 Message-ID: <51683AE1.4090503@citrix.com> References: <1365781784.15783.106.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1365781784.15783.106.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Daniel De Graaf , Keir Fraser , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 12/04/13 16:49, Ian Campbell wrote: > On Fri, 2013-04-12 at 16:41 +0100, Keir Fraser wrote: >> We could get rid of this not-always-faulting-cpuid hack in the >> hypervisor altogether, if we could provide a paravirtualised interface >> that guarantees access to the real CPUID space, for the toolstack to >> use. > Doesn't XCP have a patch which allows access to the non-levelled cpuid > values for the toolstacks benefit? Andy C CCd... > > XCP/XenServer has a specific patch which records the real CPUID values before applying the MSRs for feature masking, which can then subsequently This allows the toolstack to recalculate the host level parity bits correctly whenever a host is added or removed from the pool, without suffering the problems of getting into a diminishing subset of features as slightly heterogeneous hardware is moved in and out of the pool. The patch is currently in the state of "Needing to be cleaned up for upstream" and is in my todo list (albeit quite far down given some recent Xen crashes found during stress testing) I can up its priority if there is a need for it. ~Andrew