[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190923191250.GC19996@redhat.com>
Date: Mon, 23 Sep 2019 15:12:50 -0400
From: Andrea Arcangeli <aarcange@...hat.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
Peter Xu <peterx@...hat.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 15/17] KVM: retpolines: x86: eliminate retpoline from
vmx.c exit handlers
On Mon, Sep 23, 2019 at 11:15:58AM -0700, Sean Christopherson wrote:
> On the flip side, using a switch for the fast-path handlers gives the
> compiler more flexibility to rearrange and combine checks. Of course that
> doesn't mean the compiler will actually generate faster code for our
> purposes :-)
>
> Anyways, getting rid of the retpolines is much more important.
Precisely because of your last point, if we throw away the
deterministic priority, then we could drop the whole structure like
Vitaly suggested and we'd rely on gcc to add the indirect jump on a
non-retpoline build.
Solving the nested if we drop the structure and we don't pretend to
make it const, isn't tricky: it only requires one more check if nested
is enabled. The same variable that will have to be checked is also the
variable that needs to be checked in the
kvm_x86_ops->check_nested_events replacement later to drop the
kvm_x86_ops struct as a whole like kvm_pmu_ops was dropped clean.
Powered by blists - more mailing lists