From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: PV-vNUMA issue: topology is misinterpreted by the guest Date: Fri, 17 Jul 2015 11:17:20 +0100 Message-ID: <55A8D630.7070705@citrix.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> <55A7E2D8.3040203@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZG2hp-0001SF-W8 for xen-devel@lists.xenproject.org; Fri, 17 Jul 2015 10:17:26 +0000 In-Reply-To: <55A7E2D8.3040203@oracle.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: Boris Ostrovsky , Jan Beulich Cc: Elena Ufimtseva , Wei Liu , Dario Faggioli , David Vrabel , "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org On 16/07/15 17:59, Boris Ostrovsky wrote: > 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, 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). The current state of cpuid handling is fragile to say the least. Overriding that leaf might indeed work, if configured from the toolstack level. It can't be clobbered in the hypervisor (like some of the existing cpuid clobbering) as that would break migration. > > 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. For better or for worse, lots of software running in VMs have licensing restrictions on CPU topology. XenServer has options to configure the visible topology inside the VM, to work around the issue that currently every vcpu looks like a separate socket. ~Andrew