From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 16 Jul 2018 20:41:33 -0000 Received: from mga03.intel.com ([134.134.136.65]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ffAJH-0003zE-BV for speck@linutronix.de; Mon, 16 Jul 2018 22:41:32 +0200 Date: Mon, 16 Jul 2018 13:41:26 -0700 From: "Luck, Tony" Subject: [MODERATED] Re: [PATCH] L1TF KVM ARCH_CAPABILITIES #2 Message-ID: <20180716204125.GA2000@agluck-desk> References: <20180715135716.1874-1-pbonzini@redhat.com> <20180715135716.1874-3-pbonzini@redhat.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Mon, Jul 16, 2018 at 10:31:31PM +0200, speck for Thomas Gleixner wrote: > The magic PDF says: > > A nested VMM that finds IA32_FLUSH_CMD is enumerated should check whether > IA32_ARCH_CAPABILITIES bit 3 9 (SKIP_L1DFL_VMENTRY) is set, which indicates > that it is not required to flush L1D on VMENTER. > > First-level VMMs which perform an L1D flush before VMENTER may set > SKIP_L1DFL_VMENTRY in the IA32_ARCH_CAPABILITIES value exposed to guests. > These VMMs should set SKIP_L1DFL_VMENTRY in any case where a nested VMM may > be present. This is intended as an optimization to stop uselessly re-flushing L1D on entry to a stack of nested VMMs. E.g. if you are running a VMM "A", which is running a nested VMM "B", which is running a guest "C". When C does something to cause a VMEXIT we will pop all the way out to "A". It can take whatever action it needs, and then do a flush L1D before the VMENTER back into "B". Now "B" won't need to flush L1D again before doing the VMENTER to get back into "C". So it is just a s/w convention to let nested VMMs on systems vulnerable to L1TF know that they *are* nested VMMs and they can skip just this one part of mitigation. -Tony