From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com ([192.55.52.43]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fR0Jj-0002xa-Ku for speck@linutronix.de; Thu, 07 Jun 2018 21:11:28 +0200 From: Tim Chen 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> <55fb75e8-d57f-29b3-5255-3be0677c2452@linux.intel.com> Message-ID: Date: Thu, 7 Jun 2018 12:11:21 -0700 MIME-Version: 1.0 In-Reply-To: <55fb75e8-d57f-29b3-5255-3be0677c2452@linux.intel.com> Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="7HS4m2SNUfYMava3wwWXg3Qb4wAkZQ5Z2"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --7HS4m2SNUfYMava3wwWXg3Qb4wAkZQ5Z2 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 --7HS4m2SNUfYMava3wwWXg3Qb4wAkZQ5Z2 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/05/2018 04:37 PM, Tim Chen wrote: > On 06/05/2018 04:34 PM, Tim Chen wrote: >> 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 wr= ote: >>>> [resending as new message as the replay seems to have been lost on a= t >>>> 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 t= he >>>>> source data is in the TLB. Why that is needed is still a mystery t= hough. >>>> >>>> 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 interfe= re >>>> with the actual flushing later, either for performance reasons or fo= r >>>> preventing leakage of partial walk results. >>>> >>>> Not sure about the 64K, it likely is about the LRU implementation fo= r 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 small= er >>>> recommendations for that (52K). >>> >> >> Had some discussions with other Intel folks. >> >> Our recommendation is not to use the software sequence for L1 clear bu= t >> 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. >=20 > I will try to see if I can get hold of the relevant documentation > on pseudo LRU. >=20 The HW folks mentioned that if we have nothing from the flush buffer in L1, then 32 KB would be sufficient (if we load miss for everything). However, that's not the case. If some data from the flush buffer is already in L1, it could protect an unrelated line that's considered "near" by the LRU from getting flushed. To make sure that does not happen, we go through 64 KB of data to guarantee every line in L1 will encounter a load miss and is flushed. Tim --7HS4m2SNUfYMava3wwWXg3Qb4wAkZQ5Z2--