From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227n1OgjzoZWPKBAogHlXhUX6haeM5YhhX5VHJemoh+UtRLq5bpbRWyZ4XRf8IMUcSkJYFrw ARC-Seal: i=1; a=rsa-sha256; t=1517247102; cv=none; d=google.com; s=arc-20160816; b=DN2LvF3UTw3vxjqepztyQ46Rtp5vX5PxDH5QwRcobo7dYNGLnmT+Hg/CATO5FCYRAF /na6P4R/JZsGz4ispjafga9MgRbfDM4/d52HgvTsETJjyWHCJwvHGYNxSuecwiNg54Lj rRoNwMoKMELVgEgRsfxdsk4CTwdT/KmmQU+lSP+BWpHSJARG08jozXVASMAJSJJKt5Dt 2PHo35MSZnwTNdJhN0BM76FCF3sUdqu9hvyqOH6r5LBjxDEujjSziCDcE+trL7ljI9TC JGOnPcxOcAJxzUfOb66bh3SWK/Tf9ByVnqn2ZLy8MrGxV48GS+RInkLJIS20m5njcQKq Wi/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=La+lvwd1Sxfif2LZmwrKHC6OmPrUknyMz+2plu+6eBA=; b=MpnS8yiClB2EG5LW5T7rTa35e92D3kgUHVg/tef1OrdttSiI/N6d78Z2ijDFuckMPq VdLnlm4tocfSXhkGrX5b3Vfff8fkjT3QGuEL3XHhyo1G/0zey5BurYXpJx06hZdr9Ieh vuDVf4w2DwMC9kOmuOZdwvAAQYrCGJWsJm+AL3aNkw+gKKd3qeVf5YTXh3Xi6mOaOsM0 tgNGrhoW7G6Z1o+Yreq17YxMcZ6RiFAVnDRIJEsN/H1Ip/Tu2KwP507M6JNBsod3CDdL sXFofm/DKPvhnsF3XycGoI2ESselxvDNkVy99IOEz3SRPnAV8FQoS2t/sOb2BYDWL9k8 JEDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=r1mr2kc1; spf=pass (google.com: domain of konrad.wilk@oracle.com designates 141.146.126.78 as permitted sender) smtp.mailfrom=konrad.wilk@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=r1mr2kc1; spf=pass (google.com: domain of konrad.wilk@oracle.com designates 141.146.126.78 as permitted sender) smtp.mailfrom=konrad.wilk@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Date: Mon, 29 Jan 2018 12:31:13 -0500 From: Konrad Rzeszutek Wilk To: David Woodhouse , daniel.kiper@oracle.com, Mihai Carabas Cc: Liran Alon , luto@kernel.org, tglx@linutronix.de, torvalds@linux-foundation.org, gregkh@linuxfoundation.org, asit.k.mallick@intel.com, dave.hansen@intel.com, karahmed@amazon.de, jun.nakajima@intel.com, dan.j.williams@intel.com, ashok.raj@intel.com, daniel.kiper@oracle.com, arjan.van.de.ven@intel.com, tim.c.chen@linux.intel.com, pbonzini@redhat.com, linux-kernel@vger.kernel.org, ak@linux.intel.com, kvm@vger.kernel.org, aarcange@redhat.com Subject: Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL Message-ID: <20180129173113.GO22045@char.us.oracle.com> References: <6b9a1ec2-5ebd-4624-a825-3f31db5cefb5@default> <1517215563.6624.118.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1517215563.6624.118.camel@infradead.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8789 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=949 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801290226 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590865729989295970?= X-GMAIL-MSGID: =?utf-8?q?1590948897788603501?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 29, 2018 at 08:46:03AM +0000, David Woodhouse wrote: > On Sun, 2018-01-28 at 16:39 -0800, Liran Alon wrote: > > > > Windows use IBRS and Microsoft don't have any plans to switch to retpoline. > > Running a Windows guest should be a pretty common use-case no? > > > > In addition, your handle of the first WRMSR intercept could be different. > > It could signal you to start doing the following: > > 1. Disable intercept on SPEC_CTRL MSR. > > 2. On VMEntry, Write vCPU SPEC_CTRL value into physical MSR. > > 3. On VMExit, read physical MSR into vCPU SPEC_CTRL value. > > (And if IBRS is used at host, also set physical SPEC_CTRL MSR here to 1) > > > > That way, you will both have fastest option as long as guest don't use IBRS > > and also won't have the 3% performance hit compared to Konrad's proposal. > > > > Am I missing something? > > Reads from the SPEC_CTRL MSR are strangely slow. I suspect a large part > of the 3% speedup you observe is because in the above, the vmentry path > doesn't need to *read* the host's value and store it; the host is > expected to restore it for itself anyway? Yes for at least the purpose of correctness. That is based on what I have heard is that you when you transition to a higher ring you have to write 1, then write zero when you transition back to lower rings. That is it is like a knob. But then I heard that on some CPUs it is more like reset button and just writting 1 to IBRS is fine. But again, correctness here. > > I'd actually quite like to repeat the benchmark on the new fixed > microcode, if anyone has it yet, to see if that read/swap slowness is > still quite as excessive. I'm certainly not ruling this out, but I'm > just a little wary of premature optimisation, and I'd like to make sure > we have everything *else* in the KVM patches right first. > > The fact that the save-and-restrict macros I have in the tip of my > working tree at the moment are horrid and causing 0-day nastygrams, > probably doesn't help persuade me to favour the approach ;) > > ... hm, the CPU actually has separate MSR save/restore lists for > entry/exit, doesn't it? Is there any way to sanely make use of that and > do the restoration manually on vmentry but let it be automatic on > vmexit, by having it *only* in the guest's MSR-store area to be saved > on exit and restored on exit, but *not* in the host's MSR-store area? Oh. That sounds sounds interesting > > Reading the code and comparing with the SDM, I can't see where we're > ever setting VM_EXIT_MSR_STORE_{ADDR,COUNT} except in the nested > case... Right. We (well Daniel Kiper, CC-ed) implemented it for this and that is where we got the numbers. Daniel, you OK posting it here? Granted with the caveats thta it won't even compile against upstream as it was based on a distro kernel.