All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Yang Zhang <yang.z.zhang@intel.com>,
	kvm@vger.kernel.org, haitao.shan@intel.com,
	Kevin Tian <kevin.tian@intel.com>
Subject: Re: [PATCH v7 2/3] x86, apicv: add virtual interrupt delivery support
Date: Thu, 20 Dec 2012 21:07:47 -0200	[thread overview]
Message-ID: <20121220230747.GB18767@amt.cnet> (raw)
In-Reply-To: <20121220131232.GG17584@redhat.com>

On Thu, Dec 20, 2012 at 03:12:32PM +0200, Gleb Natapov wrote:
> On Thu, Dec 20, 2012 at 10:53:16AM -0200, Marcelo Tosatti wrote:
> > On Thu, Dec 20, 2012 at 08:42:06AM +0200, Gleb Natapov wrote:
> > > On Wed, Dec 19, 2012 at 10:59:36PM -0200, Marcelo Tosatti wrote:
> > > > On Mon, Dec 17, 2012 at 01:30:49PM +0800, Yang Zhang wrote:
> > > > > From: Yang Zhang <yang.z.zhang@Intel.com>
> > > > > 
> > > > > Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
> > > > > manually, which is fully taken care of by the hardware. This needs
> > > > > some special awareness into existing interrupr injection path:
> > > > > 
> > > > > - for pending interrupt, instead of direct injection, we may need
> > > > >   update architecture specific indicators before resuming to guest.
> > > > > 
> > > > > - A pending interrupt, which is masked by ISR, should be also
> > > > >   considered in above update action, since hardware will decide
> > > > >   when to inject it at right time. Current has_interrupt and
> > > > >   get_interrupt only returns a valid vector from injection p.o.v.
> > > > > 
> > > > > Signed-off-by: Kevin Tian <kevin.tian@intel.com>
> > > > > Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
> > > > 
> > > > 
> > > > Resuming previous discussion:
> > > > 
> > > > > > How about to recaculate irr_pending according the VIRR on each
> > > > > > vmexit?
> > > > > > 
> > > > > No need really. Since HW can only clear VIRR the only situation that
> > > > > may
> > > > > happen is that irr_pending will be true but VIRR is empty and
> > > > > apic_find_highest_irr() will return correct result in this case.
> > > > 
> > > > Self-IPI does cause VIRR to be set, see "29.1.5 Self-IPI 
> > > > Virtualization".
> > > >
> > > True. But as I said later in that discussion once irr_pending is set
> > > to true it never becomes false, so the optimization is effectively
> > > disable. We can set it to true doing apic initialization to make it
> > > explicit.
> > 
> > Its just confusing, to have a variable which has different meanings
> > in different configurations. I would rather have it explicit that 
> > its not used rather than check every time the i read the code.
> > 
> > if (apic_vid() == 0 && !apic->irr_pending)
> > 	return -1;
> > 
> I'd prefer to avoid this additional if() especially as its sole purpose
> is documentation.  We can add comment instead. Note that irr_pending
> is just a hint anyway.  It can be true when no interrupt is pending in
> irr. We can even rename it to irr_pending_hint or something.

Works for me (documentation).

> > Not sure if you can skip it, its probably necessary to calculate it
> > before HW does so (say migration etc).
> kvm_apic_has_interrupt() is not called during migration and
> kvm_apic_post_state_restore() calls apic_update_ppr() explicitly.
> I am not sure it is needed though since migrated value should be already
> correct anyway.

Ok, best force isr_count to 1 if apic vintr enabled (and add a comment,
please).


  reply	other threads:[~2012-12-20 23:07 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-17  5:30 [PATCH v7 0/3] x86, apicv: Add APIC virtualization support Yang Zhang
2012-12-17  5:30 ` [PATCH v7 1/3] x86, apicv: add APICv register " Yang Zhang
2012-12-17  5:30 ` [PATCH v7 2/3] x86, apicv: add virtual interrupt delivery support Yang Zhang
2012-12-20  0:59   ` Marcelo Tosatti
2012-12-20  1:01     ` Marcelo Tosatti
2012-12-20  6:42     ` Gleb Natapov
2012-12-20 12:53       ` Marcelo Tosatti
2012-12-20 13:12         ` Gleb Natapov
2012-12-20 23:07           ` Marcelo Tosatti [this message]
2012-12-25  7:49             ` Zhang, Yang Z
2012-12-20  1:26   ` Marcelo Tosatti
2012-12-20  6:51     ` Gleb Natapov
2012-12-20 13:01       ` Marcelo Tosatti
2012-12-20 13:02         ` Marcelo Tosatti
2012-12-20 22:00   ` Marcelo Tosatti
2012-12-27  3:32     ` Zhang, Yang Z
2012-12-27  6:20       ` Gleb Natapov
2012-12-27  6:34         ` Zhang, Yang Z
2012-12-27  6:38           ` Gleb Natapov
2012-12-27  6:50             ` Zhang, Yang Z
2012-12-20 22:59   ` Marcelo Tosatti
2012-12-21  7:51     ` Gleb Natapov
2012-12-21 11:39       ` Marcelo Tosatti
2012-12-21 12:08         ` Gleb Natapov
2012-12-27  2:24           ` Zhang, Yang Z
2012-12-27  6:23             ` Gleb Natapov
2012-12-27  6:25               ` Zhang, Yang Z
2012-12-31 15:02                 ` Marcelo Tosatti
2012-12-17  5:30 ` [PATCH v7 3/3] x86, apicv: add virtual x2apic support Yang Zhang
2012-12-20  8:31   ` Gleb Natapov
2012-12-24  1:41     ` Zhang, Yang Z
2012-12-24  2:35     ` Zhang, Yang Z
2012-12-24  9:23       ` Gleb Natapov
2012-12-24 23:53         ` Zhang, Yang Z
2012-12-25  6:38           ` Gleb Natapov
2012-12-25  6:42             ` Zhang, Yang Z
2012-12-25  6:50               ` Gleb Natapov
2012-12-25  7:25                 ` Zhang, Yang Z
2012-12-25  7:31                   ` Gleb Natapov
2012-12-25  7:46                     ` Zhang, Yang Z
2012-12-25  7:52                       ` Gleb Natapov
2012-12-25  8:24                         ` Zhang, Yang Z
2012-12-25 11:58                           ` Gleb Natapov

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=20121220230747.GB18767@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=gleb@redhat.com \
    --cc=haitao.shan@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.