From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fQ0jN-0000we-66 for speck@linutronix.de; Tue, 05 Jun 2018 03:25:49 +0200 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CCB6140BC064 for ; Tue, 5 Jun 2018 01:25:42 +0000 (UTC) Received: from washington.bos.jonmasters.org (ovpn-122-93.rdu2.redhat.com [10.10.122.93]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 948D2202698A for ; Tue, 5 Jun 2018 01:25:42 +0000 (UTC) Subject: [MODERATED] Re: Is: Tim, Q to you. Was:Re: [PATCH 1/2] L1TF KVM 1 References: <20180529194214.2600-1-pbonzini@redhat.com> <20180529194240.7F1336110A@crypto-ml.lab.linutronix.de> <99e589e5-6385-2e3e-aac4-6a5d6955a505@redhat.com> <0263eeab-7c6a-20e4-324a-135b97bc1691@amazon.com> <20180604131133.GB7296@char.us.oracle.com> From: Jon Masters Message-ID: Date: Mon, 4 Jun 2018 21:25:42 -0400 MIME-Version: 1.0 In-Reply-To: <20180604131133.GB7296@char.us.oracle.com> Content-Type: multipart/mixed; boundary="okWJuRtEz31wqO6BLK9dt9gKaqzFdvBc5"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --okWJuRtEz31wqO6BLK9dt9gKaqzFdvBc5 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/04/2018 09:11 AM, speck for Konrad Rzeszutek Wilk wrote: > On Mon, Jun 04, 2018 at 10:24:59AM +0200, speck for Martin Pohlack wrot= e: >> [resending as new message as the replay seems to have been lost on at >> least some mail paths] >> >> On 30.05.2018 11:01, speck for Paolo Bonzini wrote: >>> On 30/05/2018 01:54, speck for Andrew Cooper wrote: >>>> Other bits I don't understand are the 64k limit in the first place, = why >>>> it gets walked over in 4k strides to begin with (I'm not aware of an= y >>>> prefetching which would benefit that...) and why a particularly >>>> obfuscated piece of magic is used for the 64byte strides. >>> >>> That is the only part I understood, :) the 4k strides ensure that the= >>> source data is in the TLB. Why that is needed is still a mystery tho= ugh. >> >> I think the reasoning is that you first want to populate the TLB for t= he >> whole flush array, then fence, to make sure TLB walks do not interfere= >> with the actual flushing later, either for performance reasons or for >> preventing leakage of partial walk results. >> >> Not sure about the 64K, it likely is about the LRU implementation for = L1 >> replacement not being perfect (but pseudo LRU), so you need to flush >> more than the L1 size (32K) in software. But I have also seen smaller= >> recommendations for that (52K). >=20 > Isn't Tim Chen from Intel on this mailing list? Tim, could you find out= > please? I had assumed it was for the more straightforward reason that $future uarch has a 64K L1D$, at least according to "The Internet" (TM): https://en.wikichip.org/wiki/intel/core_i3/i3-8121u It ought to be associativity that impacts the displacement itself, not the LRU policy since you still end up with the L1D being updated. Jon. --=20 Computer Architect | Sent from my Fedora powered laptop --okWJuRtEz31wqO6BLK9dt9gKaqzFdvBc5--