lists.openwall.net   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  linux-cve-announce  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:   Fri, 14 Oct 2016 15:37:38 +0800
From:   Yang Zhang <yang.zhang.wz@...il.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        "Wu, Feng" <feng.wu@...el.com>,
        "Michael S. Tsirkin" <mst@...hat.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "rkrcmar@...hat.com" <rkrcmar@...hat.com>
Subject: Re: [PATCH 2/3] kvm: x86: do not use KVM_REQ_EVENT for APICv
 interrupt injection

On 2016/9/28 19:50, Paolo Bonzini wrote:
>
>
> On 28/09/2016 13:40, Wu, Feng wrote:
>> IIUIC, the issue you describe above is that IPI for posted-interrupts may be
>> issued between
>>
>> vcpu->mode = IN_GUEST_MODE;
>>
>> and
>>
>> local_irq_disable();
>>
>> But if that really happens, we will call kvm_vcpu_kick() in
>> vmx_deliver_posted_interrupt(), hence the vcpu->mode will be changed
>> to EXITING_GUEST_MODE, then we will goto cancel_injection in
>> vcpu_enter_guest, so the posted-interrupt will be delivered to guest
>> in the next vmentry. Seems I cannot see the problem. Do I miss something?
>
> No, if that happens kvm_trigger_posted_interrupt returns true, hence
> kvm_vcpu_kick is not called.  With the fix, the IPI is processed as soon
> as the guest enters non-root mode, and the interrupt is injected.
>
>
> The other issue occurs when the IPI is sent between
>
>                         kvm_x86_ops->hwapic_irr_update(vcpu,
>                                 kvm_lapic_find_highest_irr(vcpu));
>
> and
>
> 	vcpu->mode = IN_GUEST_MODE;
>
> In this case, kvm_vcpu_kick is called but it (correctly) doesn't do
> anything because it sees vcpu->mode == OUTSIDE_GUEST_MODE.  Then the
> guest is entered with PIR.ON, but the PI interrupt is not pending and
> hence the interrupt is never delivered to the guest.  The fix for this
> is to move the RVI update after IN_GUEST_MODE.  Then the source CPU uses
> the posted interrupt IPI instead of kvm_cpu_kick, and everything works.

Please ignore my previous reply. It seems you already aware the issue 
and get the resolution to fix it.:-)


-- 
Yang
Alibaba Cloud Computing

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ