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] [day] [month] [year] [list]
Message-ID: <82D7661F83C1A047AF7DC287873BF1E172CD574E@SHSMSX101.ccr.corp.intel.com>
Date:   Wed, 30 Jan 2019 00:37:43 +0000
From:   "Kang, Luwei" <luwei.kang@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.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

> >>> 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.
> 
Hi Paolo
    Thanks for your elaboration, very clear to me. I will fix it in next version.

Thanks,
Luwei Kang



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ