From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: PV-vNUMA issue: topology is misinterpreted by the
	guest
Date: Thu, 16 Jul 2015 12:59:04 -0400
Message-ID: <55A7E2D8.3040203@oracle.com>
References: <1437042762.28251.18.camel@citrix.com>
	<55A7A7F40200007800091D60@mail.emea.novell.com>
	<55A78DF2.1060709@citrix.com>
	<20150716152513.GU12455@zion.uk.xensource.com>
	<55A7D17C.5060602@citrix.com> <55A7D2CC.1050708@oracle.com>
	<55A7F7F40200007800092152@mail.emea.novell.com>
	<55A7DE45.4040804@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1ZFmVR-0000dM-74
	for xen-devel@lists.xenproject.org; Thu, 16 Jul 2015 16:59:33 +0000
In-Reply-To: <55A7DE45.4040804@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>, Wei Liu <wei.liu2@citrix.com>, Dario Faggioli <dario.faggioli@citrix.com>, David Vrabel <david.vrabel@citrix.com>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
List-Id: xen-devel@lists.xenproject.org

On 07/16/2015 12:39 PM, Andrew Cooper wrote:
> On 16/07/15 17:29, Jan Beulich wrote:
>>>>> On 16.07.15 at 17:50, <boris.ostrovsky@oracle.com> wrote:
>>> Can't we set leaf 1's EBX[32:16] to 1?

(I obviously fat-fingered this --- I meant EBX[23:16])

>> I don't think we should partially overwrite the relevant parts of
>> CPUID output - either all or nothing (so that things at least
>> remain consistent).

Possibly more, but specifically for Dario's problem I think this could 
resolve that.

> Also, there are no masking/override MSRs for that feature leaf on any
> hardware I am aware of, and a PV guest using plain `cpuid` will not
> observe any attempt of Xen's to control the value.

True, but we already modify other CPUID bits (e.g. we clear 
X86_FEATURE_TOPOEXT) so it won't make things much worse. (And again, for 
this specific problem CPUID is queried by guest kernel which uses PV 
CPUID instruction).

And in general (both for PV and HVM) --- is there any reason to expose 
CPU topology at all? I can see it being useful if VCPUs are pinned but 
if they are not then it can make performance worse.

-boris