public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: "Li, Jiongxi" <jiongxi.li@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 4/5]KVM:x86, apicv: add interface for poking EOI exit bitmap
Date: Sun, 16 Sep 2012 12:53:47 +0300	[thread overview]
Message-ID: <5055A1AB.6010203@redhat.com> (raw)
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB8781AF8@SHSMSX101.ccr.corp.intel.com>

On 09/14/2012 05:19 PM, Li, Jiongxi wrote:
> Sorry for the late response
> 
>> -----Original Message-----
>> From: Avi Kivity [mailto:avi@redhat.com]
>> Sent: Friday, September 07, 2012 12:38 AM
>> To: Li, Jiongxi
>> Cc: kvm@vger.kernel.org
>> Subject: Re: [PATCH 4/5]KVM:x86, apicv: add interface for poking EOI exit
>> bitmap
>> 
>> On 09/05/2012 08:41 AM, Li, Jiongxi wrote:
>> > With APICv virtual interrupt delivery feature, EOI write from non root
>> > mode doesn't cause VM-Exit unless set in EOI exit bitmap VMCS field.
>> > Basically there're two methods to manipulate EOI exit bitmap:
>> 
>> Should be folded into the previous patch, otherwise the previous patch breaks
>> level interrupts.
> OK
>> 
>> >
>> > [Option 1]
>> > Ideally only level triggered irq requires a hook in vLAPIC EOI write,
>> > so that vIOAPIC EOI is triggered and emulated. So the simplest
>> > approach is to manipulate EOI exit bitmap when vLAPIC acks a new
>> > interrupt, based on value of TMR. There're several corner cases worthy
>> > of note though:
>> >
>> >   - KVM has specific notifier hooks on vIOAPIC EOI path. So far two
>> >     sources use it: INT-based device passthrough and PIT pending
>> >     timers. For the former, it's virtually wired to vIOAPIC and
>> >     thus TMR already covers it. PIT is special here, which is an
>> >     edge triggered source. But since other timer sources like
>> >     vLAPIC timer don't require this notifier hook, possibly PIT
>> >     can be relaxed in the future too.
>> 
>> I would like to switch to changing the timer frequency when we need to catch
>> up.  But that can be done later.
>> 
>> >
>> >   - posted interrupt will update TMR directly, w/o chance for KVM
>> >     to update EOI exit bitmap accordingly. This becomes a gap
>> 
>> Why not? we know what vector the PIT is wired to.
> What PIT case are you talking about? Can you elaborate it?
>> 

The PIT output is wired to the IOAPIC, and has an ack notifier set so we
are notified on EOI (and can reinject missing ticks).

All other interrupts for which we need EOI notification are always level
triggered, and we have ack notifiers for them too.




-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-09-16  9:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-05  5:41 [PATCH 4/5]KVM:x86, apicv: add interface for poking EOI exit bitmap Li, Jiongxi
2012-09-06 16:37 ` Avi Kivity
2012-09-14 14:19   ` Li, Jiongxi
2012-09-16  9:53     ` Avi Kivity [this message]
2012-09-17 11:28   ` Li, Jiongxi
2012-09-19 14:45     ` Avi Kivity

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=5055A1AB.6010203@redhat.com \
    --to=avi@redhat.com \
    --cc=jiongxi.li@intel.com \
    --cc=kvm@vger.kernel.org \
    /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