[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <82D7661F83C1A047AF7DC287873BF1E172CD4BDD@SHSMSX101.ccr.corp.intel.com>
Date: Tue, 29 Jan 2019 09:32:36 +0000
From: "Kang, Luwei" <luwei.kang@...el.com>
To: "Kang, Luwei" <luwei.kang@...el.com>,
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". Because there indeed have this two flag check in vmx_deliver_posted_interrupt() function. If PID.ON is already Set at the time of hardware posting an interrupt to PIR field, notification event is not generated (from VT-d spec 9.12).
Thanks,
Luwei Kang
Powered by blists - more mailing lists