From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1517222842; cv=none; d=google.com; s=arc-20160816; b=jm0LBH0U2XOPsj63xJYepcbp9wVhaho6aDo4uU5PeVZeUyAE0HT56aC9YHXKI/vODn LVtJe39XVWegymeqGujqfXYOzW2kxJuPftkL9LCMk9Lfg8UurSyWe9Gj2wkTdbTugscd b0PtUAzh3saIpgE7gRL1Hj7CcNLTUf0061bmN0VPV6sRDYShfgwnQ8XKtYPFkgRHS24H +hLWsT5GOq+mGVtUZTEomlL8Ty+dHEU2YepKz0lv/fJyjmK0eoMqXcSl9TgmVXRMWmmR SSILE2tYOsPLnPoDgnpyzIpS1Z9QPKXgjw23EsvUiFrg9vI5ahuPmonmmSlSqfmdji8F x79A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject:sender :dkim-signature:arc-authentication-results; bh=OzSIsNPlVZ62EYUT5YEPXE/UwDWJETIP9r8eQ+1DmG8=; b=VrHWrAEDuBNXx2SbZHCo/J0CLyODF6m5fTPtbZomhICVPlrO9OkEvterK7FIpni/w6 ovUShFLuZwqAZFqSp+3+M2Yq91ua6LnlV05zf68cGEcBX0s9bBBif8UxBCXILEXsaLJD QlecNX0fVDr/BTp6OnoRD4UBL68JigBE7Koe29aY7xStgXJJWYdl+LSEu33RebobcOIs oK6Ml8UFStXMXCnLY49j2QSIvfbSXGLf6OMYFlhrIKq6teTdoO/oVj93r40A9h5xTe5Z sJo8fJ1CAcM5S54WSWzwDa4mHg7SWxYkUMfJGM4ATVBGsGk++g7rrJVEc/pifh6C3cwZ kAYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=pB4dTo5S; spf=pass (google.com: domain of paolo.bonzini@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=paolo.bonzini@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=pB4dTo5S; spf=pass (google.com: domain of paolo.bonzini@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=paolo.bonzini@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Google-Smtp-Source: AH8x224qt/2Ms4CVLOfZSOfZnW2f5jHNQAgoOshZJBlD3OJ7ti5jEHZdLCeclfrhwp5QoeLNalCuPw== Sender: Paolo Bonzini Subject: Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL To: David Woodhouse , Liran Alon Cc: konrad.wilk@oracle.com, 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, linux-kernel@vger.kernel.org, ak@linux.intel.com, kvm@vger.kernel.org, aarcange@redhat.com References: <6b9a1ec2-5ebd-4624-a825-3f31db5cefb5@default> <1517215563.6624.118.camel@infradead.org> From: Paolo Bonzini Message-ID: <15dec0b0-4467-a667-e940-83c29eb9fde3@redhat.com> Date: Mon, 29 Jan 2018 11:47:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1517215563.6624.118.camel@infradead.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590865729989295970?= X-GMAIL-MSGID: =?utf-8?q?1590923459080349804?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 29/01/2018 09:46, David Woodhouse wrote: > 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? Right now we don't even use the store-on-vmexit list at all, so the Simplest Patch That Can Possibly Work is definitely the one using rdmsr/wrmsr. It's not really premature optimization---though it doesn't hurt that it isn't awfully slow. Paolo