Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL
To:     David Woodhouse <dwmw2@infradead.org>,
        Liran Alon <liran.alon@oracle.com>
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 <pbonzini@redhat.com>
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
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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