From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fNJMa-0007z7-1a for speck@linutronix.de; Mon, 28 May 2018 16:43:08 +0200 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1861B81663C4 for ; Mon, 28 May 2018 14:43:02 +0000 (UTC) Received: from [10.36.118.75] (unknown [10.36.118.75]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 77B6A2166BB2 for ; Mon, 28 May 2018 14:43:01 +0000 (UTC) Subject: [MODERATED] Re: L1D-Fault KVM mitigation References: <20180424090630.wlghmrpasn7v7wbn@suse.de> <20180424093537.GC4064@hirez.programming.kicks-ass.net> <1524563292.8691.38.camel@infradead.org> <20180424110445.GU4043@hirez.programming.kicks-ass.net> <1527068745.8186.89.camel@infradead.org> <20180524094526.GE12198@hirez.programming.kicks-ass.net> From: Paolo Bonzini Message-ID: Date: Mon, 28 May 2018 16:43:00 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="Dz0ctZ4RRBpdL39ReBlYjvzP9oGSlIYx9"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --Dz0ctZ4RRBpdL39ReBlYjvzP9oGSlIYx9 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 25/05/2018 10:31, speck for Thomas Gleixner wrote: > On Thu, 24 May 2018, speck for Linus Torvalds wrote: >> On Thu, 24 May 2018, speck for Tim Chen wrote: >>> >>> We may need to do the co-scheduling only when VM exit rate is low, an= d >>> turn off the SMT when VM exit rate becomes too high. >> >> I don't think there's any way to actually turn off HT dynamically, is = >> there? >> >> Yes, you can park the sibling in idle, but afaik, some core resources = will=20 >> still be statically partitioned, so it's different from the "turn off = HT=20 >> at boot" case. >> >> But if there is actually a way to turn HT off dynamically, maybe we co= uld=20 >> make it be CPU hotplug. That would certainly be _so_ much better than = the=20 >> nasty "turn it on/off in BIOS" even for other uses. >=20 > CPU hotplug is pretty much the only solution for runtime HT disable. In= the > current state it won't give the boot time allocated per cpu resources b= ack > and nr_present_cpus() will still be the same as before shutting them do= wn, > but everything else will be cleaned out. I need to check the scheduler > topology stuff, but that should see the change as well. We could optimi= ze > that with the static key which is already available (sched_smt_present)= , > but I have to look which nastiness is involved when toggling that at > runtime. >=20 > So yes, it's different from the case where HT is disabled in the BIOS, = but > I don't think it really matters much in practice. >=20 > I'll implement a knob in sysfs for that and see how that behaves. /me is still alive though slightly jet-lagged That was also Ingo's suggestion when I talked to him (about a month back)= =2E Also, PIO workloads are not necessarily _that_ bad because of course KVM will do only one vmexit per "rep ins". But some bootloaders are better than others. Paolo --Dz0ctZ4RRBpdL39ReBlYjvzP9oGSlIYx9--