From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fw-4101.amazon.com ([72.21.198.25]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fPknf-0000Ep-C9 for speck@linutronix.de; Mon, 04 Jun 2018 10:25:11 +0200 Received: from EX13MTAUEA001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2a-7c6d20a4.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w548P5QH003371 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Jun 2018 08:25:06 GMT From: Martin Pohlack Subject: [MODERATED] [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> Message-ID: <0263eeab-7c6a-20e4-324a-135b97bc1691@amazon.com> Date: Mon, 4 Jun 2018 10:24:59 +0200 MIME-Version: 1.0 In-Reply-To: <99e589e5-6385-2e3e-aac4-6a5d6955a505@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: [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). Martin