From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 10 Aug 2018 17:46:03 -0000 Received: from mga03.intel.com ([134.134.136.65]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1foBU9-0003Se-8f for speck@linutronix.de; Fri, 10 Aug 2018 19:46:02 +0200 Date: Fri, 10 Aug 2018 10:45:57 -0700 From: Andi Kleen Subject: [MODERATED] Re: [PATCH] SPTE masking Message-ID: <20180810174557.GI4238@tassilo.jf.intel.com> References: <20180809025756.GD4238@tassilo.jf.intel.com> <20180809174324.GE4238@tassilo.jf.intel.com> <5ed402af-86dc-cc18-16e3-fe8f50178ccd@redhat.com> <20180810172341.GH4238@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Aug 10, 2018 at 10:32:07AM -0700, speck for Linus Torvalds wrote: > > > On Fri, 10 Aug 2018, speck for Andi Kleen wrote: > > > > Normally we have the maxphyaddr reported by CPUID, and then we > > have a larger maxphyaddr which could exist because VMs are lying > > (upto 46bits) > > .. or because the CPU itself is lying. Didn't we have some CPU versions > that reported a different maxphyaddr than the CPU internally actually had? > I'm pretty sure I saw a patch that listed specific CPU versions with the > "correction" to the reported size.. Yes some client parts report a lower maxphyaddr than what the cache internally uses because their external bus supports less. But in all cases it's <= 46bits. Still not clear how that applies to Paolo's terminology. -Andi