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 ; 13 Dec 2018 19:45:10 -0000 Received: from mail-lj1-x241.google.com ([2a00:1450:4864:20::241]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gXWuz-0006ac-Bx for speck@linutronix.de; Thu, 13 Dec 2018 20:45:09 +0100 Received: by mail-lj1-x241.google.com with SMTP id n18-v6so2833662lji.7 for ; Thu, 13 Dec 2018 11:45:09 -0800 (PST) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com. [209.85.208.169]) by smtp.gmail.com with ESMTPSA id j197sm514324lfe.24.2018.12.13.11.45.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Dec 2018 11:45:02 -0800 (PST) Received: by mail-lj1-f169.google.com with SMTP id t9-v6so2839614ljh.6 for ; Thu, 13 Dec 2018 11:45:02 -0800 (PST) MIME-Version: 1.0 References: <0d6a3fbe4c511152a0f5350e62e9e09ec545f709.1544464266.git.ak@linux.intel.com> <20181211000303.GB16024@tassilo.jf.intel.com> <20181211032503.GB25620@tassilo.jf.intel.com> <20181212175803.GF25620@tassilo.jf.intel.com> In-Reply-To: From: Linus Torvalds Date: Thu, 13 Dec 2018 11:44:45 -0800 Message-ID: Subject: [MODERATED] Re: [PATCH v2 3/8] MDSv2 5 Content-Type: text/plain; charset="UTF-8" To: speck@linutronix.de List-ID: On Wed, Dec 12, 2018 at 10:47 AM Linus Torvalds wrote: > > So I'm at the Intel partner meeting right now, and the official > statement seems to be that the software sequence really shouldn't be > used. Nobody seems to want that to be used for anything but something > really odd case. Half the people on this list were probably at the meeting, so I'm not sure it needs extending on, but just to clarify: the sw version is known to not work in VM environments anyway, and really seems to be more for "documentation" than any real use. The vmvare people in particular seemed to really want the verw even if the cpuid bits didn't indicate that it does anything (because they have long lead-times to enable new CPUID bits), so their preferred sequence is basically if (!(ia32_cap & ARCH_CAP_MDS_NO)) verw(); so that it uses verw even if the cpuid bits don't say that it does anything. This is actually fairly ok, because if the verw *really* doesn't do anything, it also isn't very expensive (ie on the order of just 40 cycles instead of 400 cycles). So I'd actually be inclined to say "let's do that for the *initial* patches and back-ports" just to give any vmware users the protection. Longer term (ie after a few months), the proper sequence ends up taking X86_FEATURE_MB_CLEAR into account, so this is basically just an artificial "it takes a while for that feature to show up in a vmware cluster even after the fixes have been applied" issue. Note that vmware *really* really doesn't want that software sequence in any case. Not only does it not work reliably in virtualization anyway, it's likely that vmware cpu's *have* gotten the microcode updates, they just don't show the cpuid bits. So the software version is basically slower and less effective. Just don't do it. Do we care hugely about the odd vmvare situation? Maybe not, but considering the low cost of verw in the absence of new microcode, I do think the tradeoff is worth it. verw only gets expensive when it actually does something, and the problem is that in a vmware cloud that cpuid bit just isn't reliable. Side note: that fixes the late microcode update issue too for *this* particular case. If cpuid isn't a gating issue for the verw use, it just doesn't matter. Of course, Thomas has some good reasons to think that late microcode updates are fundamentally broken for reasons that have nothing to do with our alternate instruction case, but that's a separate issue. Linus