On Mon, Jul 23, 2018 at 12:33 PM Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > When lazy save/restore of MSR_KERNEL_GS_BASE was introduced[1], the > MSR was intercepted in all modes and was only restored for the host > when the guest is in 64-bit mode. So at the time, going through the > full host restore prior to accessing MSR_KERNEL_GS_BASE was necessary > to load host state and was not a significant waste of cycles. > > Later, MSR_KERNEL_GS_BASE interception was disabled for a 64-bit > guest[2], and then unconditionally saved/restored for the host[3]. > As a result, loading full host state is overkill for accesses to > MSR_KERNEL_GS_BASE, and completely unnecessary when the guest is > not in 64-bit mode. > > Add a dedicated utility to read/write the guest's MSR_KERNEL_GS_BASE > (outside of the save/restore flow) to minimize the overhead incurred > when accessing the MSR. When setting EFER, only decache the MSR if > the new EFER will disable long mode. > > Removing out-of-band usage of vmx_load_host_state() also eliminates, > or at least reduces, potential corner cases in its usage, which in > turn will (hopefuly) make it easier to reason about future changes > to the save/restore flow, e.g. optimization of saving host state. > > [1] commit 44ea2b1758d8 ("KVM: VMX: Move MSR_KERNEL_GS_BASE out of the vmx > autoload msr area") > [2] commit 5897297bc228 ("KVM: VMX: Don't intercept MSR_KERNEL_GS_BASE") > [3] commit c8770e7ba63b ("KVM: VMX: Fix host userspace gsbase corruption") > > Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx> Reviewed-by: Peter Shier <pshier@xxxxxxxxxx> Tested-by: Peter Shier <pshier@xxxxxxxxxx>