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 18:37:30 -0000 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1foCHx-0004Fm-Fa for speck@linutronix.de; Fri, 10 Aug 2018 20:37:29 +0200 Received: by mail-wm0-x22d.google.com with SMTP id w24-v6so2832825wmc.1 for ; Fri, 10 Aug 2018 11:37:29 -0700 (PDT) Received: from [192.168.10.165] (dynamic-adsl-78-12-156-49.clienti.tiscali.it. [78.12.156.49]) by smtp.googlemail.com with ESMTPSA id 188-v6sm3760811wmr.16.2018.08.10.11.37.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Aug 2018 11:37:22 -0700 (PDT) Sender: Paolo Bonzini Subject: [MODERATED] Re: [PATCH] SPTE masking 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> <20180810174557.GI4238@tassilo.jf.intel.com> From: Paolo Bonzini Message-ID: Date: Fri, 10 Aug 2018 20:37:19 +0200 MIME-Version: 1.0 In-Reply-To: <20180810174557.GI4238@tassilo.jf.intel.com> Content-Type: multipart/mixed; boundary="n7c1aCJFCTuo9SzKIF98dxv7px3UBBrLt"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --n7c1aCJFCTuo9SzKIF98dxv7px3UBBrLt Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/08/2018 19:45, speck for Andi Kleen wrote: > On Fri, Aug 10, 2018 at 10:32:07AM -0700, speck for Linus Torvalds wrot= e: >> On Fri, 10 Aug 2018, speck for Andi Kleen wrote: >>> Not sure I follow your definitions. What is l1tf-maxphyaddr? >>> >>> 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 version= s=20 >> that reported a different maxphyaddr than the CPU internally actually = had?=20 >> I'm pretty sure I saw a patch that listed specific CPU versions with t= he=20 >> "correction" to the reported size.. >=20 > 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 <=3D 46bits. >=20 > Still not clear how that applies to Paolo's terminology. l1tf-maxphyaddr is the real maxphyaddr, cpuid-maxphyaddr is the lower fake one reported by the CPU. If they are equal, you need to ensure that your nonpresent PTEs use unused/uncacheable portions of the address space. If they are not equal, you can use some of those reserved bits that exist in the cache but not in the PTEs. Thanks, Paolo --n7c1aCJFCTuo9SzKIF98dxv7px3UBBrLt--