From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com ([192.55.52.136]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fQLTD-00059B-Tz for speck@linutronix.de; Wed, 06 Jun 2018 01:34:32 +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: Date: Tue, 5 Jun 2018 16:34:28 -0700 MIME-Version: 1.0 In-Reply-To: <20180604131133.GB7296@char.us.oracle.com> Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="repzdawr1T60vW2Ma2wUnA77mwZCSfO1R"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --repzdawr1T60vW2Ma2wUnA77mwZCSfO1R 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 --repzdawr1T60vW2Ma2wUnA77mwZCSfO1R 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 Had some discussions with other Intel folks. Our recommendation is not to use the software sequence for L1 clear but use wrmsrl(MSR_IA32_FLUSH_L1D, MSR_IA32_FLUSH_L1D_VALUE). We expect that all affected systems will be receiving a ucode update to provide L1 clearing capability. Yes, the 4k stride is for getting TLB walks out of the way and the 64kB replacement is to accommodate pseudo LRU. Thanks. Tim --repzdawr1T60vW2Ma2wUnA77mwZCSfO1R--