From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com ([134.134.136.126]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fQLWT-0005Cv-0L for speck@linutronix.de; Wed, 06 Jun 2018 01:37:53 +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> Message-ID: <55fb75e8-d57f-29b3-5255-3be0677c2452@linux.intel.com> Date: Tue, 5 Jun 2018 16:37:49 -0700 MIME-Version: 1.0 In-Reply-To: Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="p6Ax9AlOxtalgaaPPgSMhfC588As82gUy"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --p6Ax9AlOxtalgaaPPgSMhfC588As82gUy 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 --p6Ax9AlOxtalgaaPPgSMhfC588As82gUy Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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 wro= te: >>> [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 a= ny >>>>> 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 th= e >>>> source data is in the TLB. Why that is needed is still a mystery th= ough. >>> >>> 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 interfer= e >>> 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 smalle= r >>> recommendations for that (52K). >> >=20 > Had some discussions with other Intel folks. >=20 > 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. >=20 > Yes, the 4k stride is for getting TLB walks out of the way and > the 64kB replacement is to accommodate pseudo LRU. I will try to see if I can get hold of the relevant documentation on pseudo LRU. Tim --p6Ax9AlOxtalgaaPPgSMhfC588As82gUy--