On Wed, Sep 25, 2019 at 01:03:32PM +0200, Christophe de Dinechin wrote:
>
>
> > On 23 Sep 2019, at 11:31, Vitaly Kuznetsov wrote:
> >
> > Andrea Arcangeli mailto:aarca...@redhat.com>> writes:
> >
> >> It's enough to check the exit value and issue a direct call to avoid
> >> the retpoline for a
On 24/09/19 23:46, Andrea Arcangeli wrote:
>>>
>>> I would keep only EXIT_REASON_MSR_WRITE, EXIT_REASON_PREEMPTION_TIMER,
>>> EXIT_REASON_EPT_MISCONFIG and add EXIT_REASON_IO_INSTRUCTION.
>> Intuition doesn't work great when it comes to CPU speculative
>> execution runtime. I can however run additi
On Mon, Sep 23, 2019 at 03:05:14PM -0400, Andrea Arcangeli wrote:
> On Mon, Sep 23, 2019 at 11:57:57AM +0200, Paolo Bonzini wrote:
> > On 23/09/19 11:31, Vitaly Kuznetsov wrote:
> > > +#ifdef CONFIG_RETPOLINE
> > > + if (exit_reason == EXIT_REASON_MSR_WRITE)
> > > + return h
On Tue, Sep 24, 2019 at 02:15:39AM +0200, Paolo Bonzini wrote:
> On 23/09/19 22:23, Sean Christopherson wrote:
> >
> > +int nested_vmx_handle_vmx_instruction(struct kvm_vcpu *vcpu)
> > +{
> > + switch (to_vmx(vcpu)->exit_reason) {
> > + case EXIT_REASON_VMCLEAR:
> > + return handle_
Hi Paolo,
On Tue, Sep 24, 2019 at 02:15:39AM +0200, Paolo Bonzini wrote:
> Do you really need that? Why couldn't the handle_* functions simply be
> exported from nested.c to vmx.c?
I prefer the direct call too indeed.
If Sean doesn't want to export those generic names to the whole kernel
it wou
On 24/09/19 02:35, Sean Christopherson wrote:
>> I agree. I think the way Andrea did it in his patch may not the nicest
>> but is (a bit surprisingly) the easiest and most maintainable.
> Heh, which patch? The original patch of special casing the high
> priority exits?
Yes.
Paolo
On Tue, Sep 24, 2019 at 02:16:36AM +0200, Paolo Bonzini wrote:
> On 23/09/19 23:08, Andrea Arcangeli wrote:
> > The two most attractive options to me remains what I already have
> > implemented under #ifdef CONFIG_RETPOLINE with direct calls
> > (optionally replacing the "if" with a small "switch"
On 23/09/19 23:08, Andrea Arcangeli wrote:
> The two most attractive options to me remains what I already have
> implemented under #ifdef CONFIG_RETPOLINE with direct calls
> (optionally replacing the "if" with a small "switch" still under
> CONFIG_RETPOLINE if we give up the prioritization of the
On 23/09/19 22:23, Sean Christopherson wrote:
>
> +int nested_vmx_handle_vmx_instruction(struct kvm_vcpu *vcpu)
> +{
> + switch (to_vmx(vcpu)->exit_reason) {
> + case EXIT_REASON_VMCLEAR:
> + return handle_vmclear(vcpu);
> + case EXIT_REASON_VMLAUNCH:
> + retur
On Mon, Sep 23, 2019 at 07:43:07PM -0400, Andrea Arcangeli wrote:
> On Mon, Sep 23, 2019 at 02:24:35PM -0700, Sean Christopherson wrote:
> > An extra CALL+RET isn't going to be noticeable, especially on modern
> > hardware as the high frequency VMWRITE/VMREAD fields should hit the
> > shadow VMCS.
On Mon, Sep 23, 2019 at 02:24:35PM -0700, Sean Christopherson wrote:
> An extra CALL+RET isn't going to be noticeable, especially on modern
> hardware as the high frequency VMWRITE/VMREAD fields should hit the
> shadow VMCS.
In your last email with regard to the inlining optimizations made
possibl
On Mon, Sep 23, 2019 at 05:08:38PM -0400, Andrea Arcangeli wrote:
> Hello,
>
> On Mon, Sep 23, 2019 at 01:23:49PM -0700, Sean Christopherson wrote:
> > The attached patch should do the trick.
>
> The two most attractive options to me remains what I already have
> implemented under #ifdef CONFIG_R
Hello,
On Mon, Sep 23, 2019 at 01:23:49PM -0700, Sean Christopherson wrote:
> The attached patch should do the trick.
The two most attractive options to me remains what I already have
implemented under #ifdef CONFIG_RETPOLINE with direct calls
(optionally replacing the "if" with a small "switch"
On Mon, Sep 23, 2019 at 03:05:14PM -0400, Andrea Arcangeli wrote:
> On Mon, Sep 23, 2019 at 11:57:57AM +0200, Paolo Bonzini wrote:
> > On 23/09/19 11:31, Vitaly Kuznetsov wrote:
> > > +#ifdef CONFIG_RETPOLINE
> > > + if (exit_reason == EXIT_REASON_MSR_WRITE)
> > > + return h
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
On Mon, Sep 23, 2019 at 11:57:57AM +0200, Paolo Bonzini wrote:
> On 23/09/19 11:31, Vitaly Kuznetsov wrote:
> > +#ifdef CONFIG_RETPOLINE
> > + if (exit_reason == EXIT_REASON_MSR_WRITE)
> > + return handle_wrmsr(vcpu);
> > + else if (exit_reason == EXIT_REASON_P
On Mon, Sep 23, 2019 at 01:42:44PM -0400, Andrea Arcangeli wrote:
> On Mon, Sep 23, 2019 at 06:53:10PM +0200, Paolo Bonzini wrote:
> > On 23/09/19 18:37, Sean Christopherson wrote:
> > >> Would it be too much if we get rid of
> > >> kvm_vmx_exit_handlers completely replacing this code with one swit
On Mon, Sep 23, 2019 at 06:53:10PM +0200, Paolo Bonzini wrote:
> On 23/09/19 18:37, Sean Christopherson wrote:
> >> Would it be too much if we get rid of
> >> kvm_vmx_exit_handlers completely replacing this code with one switch()?
> > Hmm, that'd require redirects for nVMX functions since they are
On 23/09/19 18:37, Sean Christopherson wrote:
>> Would it be too much if we get rid of
>> kvm_vmx_exit_handlers completely replacing this code with one switch()?
> Hmm, that'd require redirects for nVMX functions since they are set at
> runtime. That isn't necessarily a bad thing. The approach co
On Mon, Sep 23, 2019 at 11:31:58AM +0200, Vitaly Kuznetsov wrote:
> Andrea Arcangeli writes:
>
> > It's enough to check the exit value and issue a direct call to avoid
> > the retpoline for all the common vmexit reasons.
> >
> > Signed-off-by: Andrea Arcangeli
> > ---
> > arch/x86/kvm/vmx/vmx.c
Subject should be something like:
KVM: VMX: Make direct calls to fast path VM-Exit handlers
On Fri, Sep 20, 2019 at 05:25:07PM -0400, Andrea Arcangeli wrote:
> It's enough to check the exit value and issue a direct call to avoid
> the retpoline for all the common vmexit reasons.
>
> Signed-off
On 23/09/19 11:31, Vitaly Kuznetsov wrote:
> +#ifdef CONFIG_RETPOLINE
> + if (exit_reason == EXIT_REASON_MSR_WRITE)
> + return handle_wrmsr(vcpu);
> + else if (exit_reason == EXIT_REASON_PREEMPTION_TIMER)
> + return handle_preemption_t
Andrea Arcangeli writes:
> It's enough to check the exit value and issue a direct call to avoid
> the retpoline for all the common vmexit reasons.
>
> Signed-off-by: Andrea Arcangeli
> ---
> arch/x86/kvm/vmx/vmx.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
It's enough to check the exit value and issue a direct call to avoid
the retpoline for all the common vmexit reasons.
Signed-off-by: Andrea Arcangeli
---
arch/x86/kvm/vmx/vmx.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.c b/
24 matches
Mail list logo
