lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 15 Dec 2020 11:15:20 +0100
From:   Paolo Bonzini <>
To:     Andy Lutomirski <>,
        Michael Roth <>
Cc:     Sean Christopherson <>,,
        Vitaly Kuznetsov <>,
        Wanpeng Li <>,
        Jim Mattson <>,
        Joerg Roedel <>,
        Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,, "H . Peter Anvin" <>,,
        Tom Lendacky <>,
        Andy Lutomirski <>
Subject: Re: [PATCH v2] KVM: SVM: use vmsave/vmload for saving/restoring
 additional host state

On 14/12/20 23:29, Andy Lutomirski wrote:
>> One downside to that is that we'd need to do the VMSAVE on every 
>> iteration of vcpu_run(), as opposed to just once when we enter
>> from userspace via KVM_RUN. It ends up being a similar situation to
>> Andy's earlier suggestion of moving VMLOAD just after vmexit, but
>> in that case we were able to remove an MSR write to MSR_GS_BASE,
>> which cancelled out the overhead, but in this case I think it could
>> only cost us extra.
> If you want to micro-optimize, there is a trick you could play: use
> WRGSBASE if available.  If X86_FEATURE_GSBASE is available, you could
> use WRGSBASE to restore GSBASE and defer VMLOAD to vcpu_put().  This
> would need benchmarking on Zen 3 to see if it’s worthwhile.

If the improvement is big (100 cycles or so) it would be worthwhile. 
Otherwise, for the sake of code clarity doing VMLOAD in the assembly 
code is the simplest.


Powered by blists - more mailing lists