[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <994702e9-1d62-0ac4-3845-8bc9e816c284@redhat.com>
Date: Thu, 9 Mar 2017 14:11:00 +0100
From: David Hildenbrand <david@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
Wanpeng Li <kernellwp@...il.com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Cc: Radim Krčmář <rkrcmar@...hat.com>,
Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [PATCH] KVM: x86: optimize local IRQ disable time before vmentry
Am 09.03.2017 um 13:33 schrieb Paolo Bonzini:
>
>
> On 09/03/2017 13:16, Wanpeng Li wrote:
>> From: Wanpeng Li <wanpeng.li@...mail.com>
>>
>> Commit b95234c84 (kvm: x86: do not use KVM_REQ_EVENT for APICv interrupt
>> injection) disables interrupts before setting vcpu->mode to fix an race:
>>
>> | The IPI for posted interrupts may be issued between setting vcpu->mode =
>> | IN_GUEST_MODE and disabling interrupts. If that happens,
>> | kvm_trigger_posted_interrupt returns true, but smp_kvm_posted_intr_ipi
>> | doesn't do anything about it. The guest is entered with PIR.ON, but the
>> | posted interrupt IPI has not been sent and the interrupt is only delivered
>> | to the guest on the next vmentry (if any).
>>
>> However the race has already been fixed by the side-effects of moving the
>> RVI update after IN_GUEST_MODE in the commit:
>>
>> - The IPI for posted interrupts is issued after setting vcpu->mode =
>> IN_GUEST_MODE and disabling interrupts, the posted interrupt IPI is
>> delayed until the guest enters non-root mode; it is then trapped by
>> the processor causing the interrupt to be injected.
>> - The IPI for posted interrupts is issued between setting vcpu->mode =
>> IN_GUEST_MODE and disabling interrupts, the movement of the RVI update
>> after IN_GUEST_MODE in the commit will catch the new PIR, and set RVI.
>>
>> This patch tries to reduce the local IRQ disable time by restoring the
>> place of disable local IRQ in order to improve host kernel responsibility
>> to some degree.
>
> This should not make any difference; we're talking of a few dozen clock
> cycles, and it's quite possible that the extra chance of getting a PI
> interrupt in the host negates it.
>
> Paolo
>
Also, I think after all the discussion regarding handling vcpu->mode +
preemption when it comes to a vcpu_kick(), keeping it that way is way
cleaner.
--
Thanks,
David
Powered by blists - more mailing lists