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 20:50:16 -0000 Received: from mga09.intel.com ([134.134.136.24]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gXXuK-0007Oy-Kc for speck@linutronix.de; Thu, 13 Dec 2018 21:48:33 +0100 Date: Thu, 13 Dec 2018 12:48:28 -0800 From: Andi Kleen Subject: [MODERATED] Re: [PATCH v2 3/8] MDSv2 5 Message-ID: <20181213204828.GM25620@tassilo.jf.intel.com> References: <20181211000303.GB16024@tassilo.jf.intel.com> <20181211032503.GB25620@tassilo.jf.intel.com> <20181212175803.GF25620@tassilo.jf.intel.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: > 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. I think that's fine 40 cycles will be hard to measure even in the most extreme syscall micro benchmarks, and is unlikely to impact anything real. > 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. Seems odd to somehow tie our release cycle to VMware. This is something the distribution vendors would need to do anyways, as VMWare is mostly used in Enterprise environments which are likely mostly on SLES, RHEL and somesuch, and are unlikely to run raw kernel.org kernels. *Iff* we really care about this oddity, it would be best to ignore MB_CLEAR forever. AFAIK in KVM software sequences should work, as long as the administrator does not set a totally bogus CPUID (like no AVX on Sandy Bridge, or AVX with a CPU model that doesn't support AVX). We can add some documentation to make this clear. > > 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. I don't think it has been worked out yet, but the reason I added the software sequences is that some CPUs may not be able to do the VERW in microcode updates. In this case the only choice is to use software sequences, and VMware will have to deal with it somehow. But I can remove them again until that is settled. -Andi