Messages in this thread | | | Subject | Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL | From | KarimAllah Ahmed <> | Date | Mon, 29 Jan 2018 10:43:23 +0100 |
| |
On 01/29/2018 09:46 AM, 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? > > 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? > > 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...
Hmmm ... you are probably right! I think all users of this interface always trap + update save area and never passthrough the MSR. That is why only LOAD is needed *so far*.
Okay, let me sort this out in v3 then.
> Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
| |