[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <82D7661F83C1A047AF7DC287873BF1E172CD5EE4@SHSMSX101.ccr.corp.intel.com>
Date: Wed, 30 Jan 2019 09:01:23 +0000
From: "Kang, Luwei" <luwei.kang@...el.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
"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>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] KVM: x86: Sync the pending Posted-Interrupts
> > Some Posted-Interrupts from passthrough devices may be lost or
> > overwritten when the vCPU is in runnable state.
> >
> > The SN (Suppress Notification) of PID (Posted Interrupt Descriptor)
> > will be set when the vCPU is preempted (vCPU in KVM_MP_STATE_RUNNABLE
> > state but not running on physical CPU). If a posted interrupt coming
> > at this time, the irq remmaping facility will set the bit of PIR
> > (Posted Interrupt Requests) without ON (Outstanding Notification).
> > So this interrupt can't be sync to APIC virtualization register and
> > will not be handled by Guest because ON is zero.
> >
> > Signed-off-by: Luwei Kang <luwei.kang@...el.com>
> > ---
> > arch/x86/kvm/vmx/vmx.c | 2 +-
> > arch/x86/kvm/x86.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index
> > f6915f1..820a03b 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -6048,7 +6048,7 @@ static int vmx_sync_pir_to_irr(struct kvm_vcpu *vcpu)
> > bool max_irr_updated;
> >
> > WARN_ON(!vcpu->arch.apicv_active);
> > - if (pi_test_on(&vmx->pi_desc)) {
> > + if (!bitmap_empty((unsigned long *)vmx->pi_desc.pir, NR_VECTORS)) {
> > pi_clear_on(&vmx->pi_desc);
> > /*
> > * IOMMU can write to PIR.ON, so the barrier matters even on UP.
>
> This is not what I asked. You should instead do the check after pi_clear_sn.
>
I think the SN has been cleared here before test the bitmap.
The SN will be set when the vCPU is schedule out. ID: 28b835d60fcc2498e717cf5e6f0c3691c24546f7
But SN will be cleared when sched in.
Another place is when vCPU run out of the vcpu_run() function:
kvm_arch_vcpu_ioctl_run()
vcpu_load(vcpu); -> kvm_arch_vcpu_load -> vmx_vcpu_load -> vmx_vcpu_pi_load -> new.sn = 0;
vcpu_run(vcpu);
for(;;)
vcpu_put(vcpu); -> kvm_arch_vcpu_put -> vmx_vcpu_put -> vmx_vcpu_pi_put -> pi_set_sn()
But SN will be cleared in vcpu_load() before back to vcpu_run()
Thanks,
Luwei Kang
Powered by blists - more mailing lists