From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.ctxuk.citrix.com ([185.25.65.24] helo=SMTP.EU.CITRIX.COM) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fN16k-0003rI-Ri for speck@linutronix.de; Sun, 27 May 2018 21:13:35 +0200 Subject: [MODERATED] Re: L1D-Fault KVM mitigation References: <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> <20180526204319.GB4486@tassilo.jf.intel.com> <20180527182550.GC4486@tassilo.jf.intel.com> From: Andrew Cooper Message-ID: Date: Sun, 27 May 2018 20:13:24 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="Zv7ET1eXQHxkvLzPMN4lhvZ8FKo5Sir6x"; protected-headers="v1" To: speck@linutronix.de List-ID: --Zv7ET1eXQHxkvLzPMN4lhvZ8FKo5Sir6x Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 27/05/2018 19:49, speck for Linus Torvalds wrote: > > On Sun, 27 May 2018, speck for Andi Kleen wrote: >>> Maybe you mean "idle in the _host_"? >> It's both actually. Either idle in the host, or idle in the guest. > It really really isn't. > > Andi, if one sibling does a vmexit, and the other sibling is still in v= mx=20 > mode, we have to force-exit the other sibling. It doesn't matter one wh= it=20 > whether it's idle or not - because we won't know. > > Or is there some magical sideband that I am not aware of? > >> When it's idle in the host we don't need to synchronize, unless=20 >> there is an interrupt (which does its own synchronization) because >> the idle loop has nothing valuable to leak. > Right. The only case that doesn't need synchronization is "other siblin= g=20 > is idle in the _host_". > >> And if it's idle in the guest then the vcpu is blocked and >> also obviously doesn't need to be synchronized. > If the other sibling is idle inside the guest, then we don't even know = > that. > > Of course, if somebody is doing exit-on-{hlt/mwait/pause}, and we end u= p=20 > actually being in the host and _emulating_ the idle, then that might be= =20 > acceptable. Except even then we'd be potentially leaking a *lot* of hos= t=20 > caches. The vmx emulation code ends up having a not all that insignific= ant=20 > footprint in that (host percpu state, thread state etc). > > But why would you emulate halt/mwait/pause anyway? That sounds insane t= o=20 > me. The reason you would want exit-on-halt is so that the host can do=20 > something else if a vcpu goes idle, not so that it can just stay in som= e=20 > emulated idle state. > > If you want to go to low-power mode, you'd just let the halt/mwait happ= en=20 > inside the guest. > > But to be honest, I haven't actually checked what kvm users (or xen, or= =20 > whatever) really do. Am I missing something? Xen doesn't ever vcpus enter idle themselves.=A0 We trap HLT/etc and will= either schedule another VM, or choose to idle the host if there really is nothing else to do. I've never come across a plausible usecase for letting non-root mode idle the cores into a low power state.=A0 They simply aren't in a positio= n to know whether other work needs doing or not. ~Andrew --Zv7ET1eXQHxkvLzPMN4lhvZ8FKo5Sir6x--