From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp2130.oracle.com ([141.146.126.79]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fPpGx-0005x8-7y for speck@linutronix.de; Mon, 04 Jun 2018 15:11:44 +0200 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w54DBRuE181612 for ; Mon, 4 Jun 2018 13:11:35 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2jbvynuf9u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 04 Jun 2018 13:11:35 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w54DBY0b019749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 4 Jun 2018 13:11:34 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w54DBY8d028234 for ; Mon, 4 Jun 2018 13:11:34 GMT Date: Mon, 4 Jun 2018 09:11:33 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Is: Tim, Q to you. Was:Re: [PATCH 1/2] L1TF KVM 1 Message-ID: <20180604131133.GB7296@char.us.oracle.com> 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> MIME-Version: 1.0 In-Reply-To: <0263eeab-7c6a-20e4-324a-135b97bc1691@amazon.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: 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? > > Martin