From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fw-2101.amazon.com ([72.21.196.25]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fQ66l-0004jm-79 for speck@linutronix.de; Tue, 05 Jun 2018 09:10:19 +0200 Received: from EX13MTAUEA001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-9ec21598.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w557AFBu027299 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Jun 2018 07:10:16 GMT 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: Martin Pohlack Message-ID: Date: Tue, 5 Jun 2018 09:10:09 +0200 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 05.06.2018 03:25, speck for Jon Masters wrote: > 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 wrote: >>> [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 any >>>>> 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 though. >>> >>> I think the reasoning is that you first want to populate the TLB for the >>> 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). >> >> 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. Associativity should already be well covered as the flush array is laid out contiguously, so reading 32K should be enough assuming a perfect LRU implementation and no interference from the page table walker. Martin