Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp61049imu; Mon, 10 Dec 2018 16:08:05 -0800 (PST) X-Google-Smtp-Source: AFSGD/XA6xG64O8TiR9VdBpcCmK1gCjvFSXtASAO/XM8rbb028Bfn/nQ2U9d2NV/0hvHOF+YYp1r X-Received: by 2002:a63:e950:: with SMTP id q16mr12657197pgj.138.1544486885448; Mon, 10 Dec 2018 16:08:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544486885; cv=none; d=google.com; s=arc-20160816; b=hWy1CPnirlvmkIVXbYPS1kwptreuXXPGpckxRPy+OrSLDkE0oNUysM+GV49IXBN713 xencAOnPK+9dBLOz6TXBqmYqGz64iXHRlpQYU5RSMACQrossCmQxCnU6fi/BRYRh08ok Sajy0yHGgRPL1O5NYNRXqToXyInH/V1yPW/hybryV/vJQkSyak9VjQkOfYeT33K0zzbs nKLkL/Q4WCf4ZVrhBFYmphKgPZTGsjDQFhVbk9WnmrEJbo8dcUR79ZahwiTW3Z1oFSN1 26Nb3zG32WtQ30mqgMafRbE9ffEkTMw/E/9+G3oimnNuaq83S+LivvsjU9wfWgfCQ/bl 2iGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=Y42qOC3upjUGbAHvnsTBZEQ8fJw0XHVVANooxajWXPk=; b=hrzEeIch6SkknLjKyOXFNP+WkT5zTc2F+BSafIkFWBriYTLjnIYOZ3pcacomzxaip2 ZeSJo11p2M1N5UL3j2yimmz4HuL3yJu+FOA0MULI0BpW6Pn5vMEXM3w+yks8+xw6bH6c vNDIKLnF5md/DOVMGiEpHeZlQl529NdylMwN61sKC1a6+0U5IA4ypJKsKIW5fdjres8H eIxS3JhWVvw6owG3TJMOdg90K7Em5no61DGaKWEMCx54CfhgrllNh0RuYoHam6M5NRxZ 0IEC6A8eLsiAwIu9pR7SWnDEjPaoM8grn3qoEMqdSJs6Z2jHLROhfXXE6uOPVLUNAEyi Tfag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k7si10610901pgm.462.2018.12.10.16.07.50; Mon, 10 Dec 2018 16:08:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729522AbeLJVwd (ORCPT + 99 others); Mon, 10 Dec 2018 16:52:33 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:34514 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726392AbeLJVwd (ORCPT ); Mon, 10 Dec 2018 16:52:33 -0500 Received: from p4fea4820.dip0.t-ipconnect.de ([79.234.72.32] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gWTTU-00059B-Kw; Mon, 10 Dec 2018 22:52:24 +0100 Date: Mon, 10 Dec 2018 22:52:24 +0100 (CET) From: Thomas Gleixner To: Borislav Petkov cc: Andrew Cooper , Xen-devel List , "linux-kernel@vger.kernel.org" , Jan Beulich , Brian Woods , SuraveeSuthikulpanit , Boris Ostrovsky , Ingo Molnar , "H. Peter Anvin" , Tom Lendacky , Brijesh Singh Subject: Re: AMD EPYC Topology problems In-Reply-To: <20181209125648.GA15262@zn.tnic> Message-ID: References: <7369db0c-4917-0807-eef4-cba5e5ae0d4e@citrix.com> <20181203111359.GA31670@zn.tnic> <9e392fcd-4829-afe4-6f36-73d5cf03ee7c@citrix.com> <20181209125648.GA15262@zn.tnic> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 9 Dec 2018, Borislav Petkov wrote: > On Mon, Dec 03, 2018 at 11:23:49AM +0000, Andrew Cooper wrote: > > Right, but the documentation also states that where it says package, it > > means "Node" in AMD's terminology, and the information in CPUID is per > > socket, not per node. > > > > My point is that the numbers ending up in cpuinfo_x86 don't match the > > semantics described by the documentation. > > Ok, I think I know where the issue stems from: > > definition of "package" in the AMD docs != definition of "package" in Documentation/x86/topology.txt > > AMD's is "Processor: A package containing one or more Nodes." whereas > ours is: > > "Packages contain a number of cores plus shared resources, e.g. DRAM > controller, shared caches etc." > > and physical sockets we don't care about because they're not relevant to > sw. Right. Physical sockets are not interesting at all. > Yeah, lemme discuss this with tglx to refresh what we were thinking then. :) What Intel calls package is called Node on AMD. Yes, it's a mess, but we can't do much about it and as lots of existing code already used 'package' for both Intel and AMD, there was no point to invent yet another name for it. Maybe we should have... Thanks, tglx