[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <482e5526-2ee1-9ed3-19ad-3a24d56a4fc4@redhat.com>
Date: Tue, 15 Dec 2020 11:15:20 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Andy Lutomirski <luto@...capital.net>,
Michael Roth <michael.roth@....com>
Cc: Sean Christopherson <seanjc@...gle.com>, kvm@...r.kernel.org,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86@...nel.org, "H . Peter Anvin" <hpa@...or.com>,
linux-kernel@...r.kernel.org,
Tom Lendacky <thomas.lendacky@....com>,
Andy Lutomirski <luto@...nel.org>
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.
Paolo
Powered by blists - more mailing lists