linux-kernel - Re: [PATCH] KVM: x86: Sync the pending Posted-Interrupts

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]

Message-ID: <3344700c-e4df-0ef7-161a-0398d6799642@redhat.com>
Date:   Tue, 29 Jan 2019 14:30:57 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     "Kang, Luwei" <luwei.kang@...el.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Cc:     "rkrcmar@...hat.com" <rkrcmar@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>, "hpa@...or.com" <hpa@...or.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: x86: Sync the pending Posted-Interrupts

On 29/01/19 10:32, Kang, Luwei wrote:
>>> However, you should at least change the comment in vcpu_enter_guest to
>>> mention "before reading PIR" instead of "before reading PIR.ON".
>>
>> Will do that. I think the "checking PIR.ON" should be PID.ON. I will fix it.
>>
> Hi Paolo,
>     I reconsidered the comment in vcpu_enter_guest() and think it may don't need to change. The original comment as below:
>          * 2) For APICv, we should set ->mode before checking  PIR.ON.  This
>          * pairs with the memory barrier implicit in pi_test_and_set_on
>          * (see vmx_deliver_posted_interrupt).
> 
>     I think "before checking PIR.ON" is mean "before checking PID.PIR and PID.ON".

I can say it only means PID.ON because I wrote the comment. :)

The idea is that checking ON is enough: KVM assumes that PID.PIR is only
set if PID.ON is set, because it follows the definition of ON in table
29-1 of the SDM: "If this bit is set, there is a notification
outstanding for one or more posted interrupts in bits 255:0".

VT-D breaks this assumption whenever SN=1 ("hardware does not generate
notification event nor modify the ON field"), resulting in nonzero
PID.PIR but PID.ON=0.  I'm sure there was a reason for that, but it does
result in inconsistency between the PID definitions in the SDM and the
VT-D specification.  The right fix is definitely to reconcile this
difference and test the bitmap after SN is cleared (with
smp_mb__after_atomic after clearing SN), and set ON=1 if the bitmap is
not clear.

Paolo