From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com ([192.55.52.120]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fPtll-0003br-AF for speck@linutronix.de; Mon, 04 Jun 2018 19:59:49 +0200 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: Tim Chen Message-ID: <3b6bf0e0-83b0-52a8-5aa9-95eb0eb75fe6@linux.intel.com> Date: Mon, 4 Jun 2018 10:59:46 -0700 MIME-Version: 1.0 In-Reply-To: <20180604131133.GB7296@char.us.oracle.com> Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="w2K9evxzIfHWzHNhwjJzxxbJOKwxTehII"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --w2K9evxzIfHWzHNhwjJzxxbJOKwxTehII Content-Type: text/rfc822-headers; protected-headers="v1" Content-Disposition: inline From: Tim Chen To: speck for Konrad Rzeszutek Wilk Subject: Re: Is: Tim, Q to you. Was:Re: [PATCH 1/2] L1TF KVM 1 --w2K9evxzIfHWzHNhwjJzxxbJOKwxTehII Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/04/2018 06: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? >=20 Will do. Tim --w2K9evxzIfHWzHNhwjJzxxbJOKwxTehII--