From: Marcelo Tosatti <mtosatti@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Shan, Haitao" <haitao.shan@intel.com>,
"Zhang, Xiantao" <xiantao.zhang@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
"Anvin, H Peter" <h.peter.anvin@intel.com>
Subject: Re: [PATCH 2/2] x86, apicv: Add Posted Interrupt supporting
Date: Sun, 3 Feb 2013 22:57:00 -0200 [thread overview]
Message-ID: <20130204005700.GA2705@amt.cnet> (raw)
In-Reply-To: <20130131135556.GC23213@redhat.com>
On Thu, Jan 31, 2013 at 03:55:56PM +0200, Gleb Natapov wrote:
> On Thu, Jan 31, 2013 at 11:44:43AM -0200, Marcelo Tosatti wrote:
> > On Thu, Jan 31, 2013 at 03:38:37PM +0200, Gleb Natapov wrote:
> > > On Thu, Jan 31, 2013 at 11:32:45AM -0200, Marcelo Tosatti wrote:
> > > > On Thu, Jan 31, 2013 at 11:43:48AM +0200, Gleb Natapov wrote:
> > > > > On Wed, Jan 30, 2013 at 09:03:11PM -0200, Marcelo Tosatti wrote:
> > > > > > Posted interrupt patch:
> > > > > > 2) Must move IN_GUEST_MODE assignment after local_irq_disable, in
> > > > > > vcpu_enter_guest function. Otherwise:
> > > > > >
> > > > > > cpu0 vcpu1<->cpu1
> > > > > >
> > > > > > vcpu->mode = IN_GUEST_MODE
> > > > > >
> > > > > > if IN_GUEST_MODE == true
> > > > > > send IPI
> > > > > > local_irq_disable
> > > > > >
> > > > > > PIR not transferred to VIRR, misses interrupt.
> > > > > >
> > > > > cpu0 will set KVM_REQ_EVENT, so vmentry will be aborted after
> > > > > local_irq_disable() by ->requests check.
> > > >
> > > > Yes, but you don't want KVM_REQ_EVENT+kick. It defeats the purpose
> > > > of posted interrupts. You want
> > > >
> > > > if vcpu in guest mode
> > > > send posted interrupt IPI
> > > > else
> > > > KVM_REQ_EVENT+kick
> > > >
> > > I am thinking:
> > >
> > > set KVM_REQ_EVENT
> > > if pi is enabled
> > > send posted interrupt IPI
> > > else
> > > kick
> >
> > KVM_REQ_EVENT must be after sending posted interrupt IPI. Otherwise on
> > the vcpu entry side
> >
> > test_and_clear(KVM_REQ_EVENT) {
> > No bits set in PIR
> > }
> >
> It should be after updating PIR, but before sending posted interrupt
> IPI. Otherwise:
>
> cpu0 cpu1/vcpu
>
> KVM_REQ_EVENT is not set
> set pir
> send IPI
> irq_disable()
> ->request is empty.
> set KVM_REQ_EVENT
>
> That's the same sequence as with IRR update, KVM_REQ_EVENT and kick
> today.
Can only send IPI if vcpu->mode == IN_GUEST_MODE, which must be set
after interrupt flag is cleared as noted.
Also KVM_REQ_EVENT is processed outside of interrupt disabled region today.
Or maybe i don't get what you say... write a complete
description?
> > What about item 4 below?
> >
> That's for Yang to answer :)
"If more than one interrupt is generated with the same vector number,
the local APIC can set the bit for the vector both in the IRR and ISR.
This means that for the Pentium 4 and Intel Xeon processors, the IRR
and ISR can queue two interrupts for each interrupt vector: one in the
IRR and one in the ISR. Any additional interrupts issued for the same
interrupt vector are collapsed into the single bit in IRR"
Which would mean KVM emulation differs... "Eventually 3 interrupts can
be queued: one in IRR, one in ISR, one in PIR".
Any example how software relies on such two-interrupts-queued-in-IRR/ISR behaviour?
next prev parent reply other threads:[~2013-02-04 1:01 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-13 7:29 [PATCH 0/2] KVM: Add posted interrupt supporting Yang Zhang
2012-12-13 7:29 ` [PATCH 1/2] x86: Enable ack interrupt on vmexit Yang Zhang
2012-12-13 7:51 ` Gleb Natapov
2012-12-13 7:54 ` Zhang, Yang Z
2012-12-13 7:58 ` Gleb Natapov
2012-12-13 8:03 ` Zhang, Yang Z
2012-12-13 8:05 ` Gleb Natapov
2012-12-13 8:19 ` Zhang, Yang Z
2012-12-13 8:22 ` Gleb Natapov
2012-12-13 8:23 ` Zhang, Yang Z
2012-12-16 13:26 ` Zhang, Yang Z
2012-12-18 9:11 ` Gleb Natapov
2012-12-13 7:29 ` [PATCH 2/2] x86, apicv: Add Posted Interrupt supporting Yang Zhang
2013-01-22 22:59 ` Marcelo Tosatti
2013-01-23 5:09 ` Zhang, Yang Z
2013-01-24 23:43 ` Marcelo Tosatti
2013-01-25 0:40 ` Zhang, Yang Z
2013-01-30 23:03 ` Marcelo Tosatti
2013-01-30 23:57 ` Marcelo Tosatti
2013-01-31 7:35 ` Gleb Natapov
2013-01-31 9:43 ` Gleb Natapov
2013-01-31 13:32 ` Marcelo Tosatti
2013-01-31 13:38 ` Gleb Natapov
2013-01-31 13:44 ` Marcelo Tosatti
2013-01-31 13:55 ` Gleb Natapov
2013-02-04 0:57 ` Marcelo Tosatti [this message]
2013-02-04 9:10 ` Zhang, Yang Z
2013-02-04 9:55 ` Gleb Natapov
2013-02-04 14:43 ` Marcelo Tosatti
2013-02-04 17:13 ` Gleb Natapov
2013-02-04 19:59 ` Marcelo Tosatti
2013-02-04 20:47 ` Marcelo Tosatti
2013-02-05 5:57 ` Zhang, Yang Z
2013-02-05 8:00 ` Gleb Natapov
2013-02-05 10:35 ` Zhang, Yang Z
2013-02-05 10:54 ` Gleb Natapov
2013-02-05 10:58 ` Zhang, Yang Z
2013-02-05 11:16 ` Gleb Natapov
2013-02-05 13:26 ` Zhang, Yang Z
2013-02-05 13:29 ` Gleb Natapov
2013-02-05 13:40 ` Zhang, Yang Z
2013-02-05 13:43 ` Gleb Natapov
2013-02-07 1:23 ` Marcelo Tosatti
2013-02-05 7:32 ` Gleb Natapov
2013-02-06 22:49 ` Marcelo Tosatti
2013-02-07 0:24 ` Marcelo Tosatti
2013-02-07 13:52 ` Gleb Natapov
2013-02-08 2:07 ` Marcelo Tosatti
2013-02-08 12:18 ` Gleb Natapov
2013-02-07 14:01 ` Gleb Natapov
2013-02-07 21:49 ` Marcelo Tosatti
2013-02-08 12:28 ` Gleb Natapov
2013-02-08 13:46 ` Marcelo Tosatti
2013-01-31 9:37 ` Gleb Natapov
2013-02-04 9:11 ` Zhang, Yang Z
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130204005700.GA2705@amt.cnet \
--to=mtosatti@redhat.com \
--cc=gleb@redhat.com \
--cc=h.peter.anvin@intel.com \
--cc=haitao.shan@intel.com \
--cc=jun.nakajima@intel.com \
--cc=kvm@vger.kernel.org \
--cc=xiantao.zhang@intel.com \
--cc=yang.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox