public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Gleb Natapov <gleb@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Shan, Haitao" <haitao.shan@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>
Subject: Re: [PATCH v8 2/3] x86, apicv: add virtual interrupt delivery support
Date: Tue, 8 Jan 2013 11:57:59 -0200	[thread overview]
Message-ID: <20130108135759.GB5121@amt.cnet> (raw)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E2F3CC6@SHSMSX101.ccr.corp.intel.com>

On Tue, Jan 08, 2013 at 12:57:42PM +0000, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2013-01-08:
> > On Mon, Jan 07, 2013 at 07:32:39PM -0200, Marcelo Tosatti wrote:
> >> On Mon, Jan 07, 2013 at 07:48:43PM +0200, Gleb Natapov wrote:
> >>>> ioapic_write (or any other ioapic update)
> >>>> lock()
> >>>> perform update
> >>>> make_all_vcpus_request(KVM_REQ_UPDATE_EOI_BITMAP) (*)
> >>>> unlock()
> >>>> 
> >>>> (*) Similarly to TLB flush.
> >>>> 
> >>>> The advantage is that all work becomes vcpu local. The end result
> >>>> is much simpler code.
> >>> What complexity will it remove?
> >> 
> >> Synchronization between multiple CPUs (except the KVM_REQ_ bit
> >> processing, which is infrastructure shared by other parts of KVM).
> >> 
> > Synchronization is just a lock around bitmap access. Can be replaced
> > with RCU if it turns to be performance problem.
> > 
> >> We agreed that performance is non issue here.
> > Yes, if the code is indeed simpler we can take the hit, although
> > recalculating bitmap 255 times instead of one for -smp 255 looks like a
> > little bit excessive, but I do not see considerable simplification (if
> > at all).
> > 
> > So as far as I understand you are proposing:
> > 
> > vcpu0 or io thread:                   |    vcpu1:
> > ioapic_write (or other ioapic update) |
> >  lock(exitbitmap)                     |
> >  if (on vcpu)                         |
> >    ioapic_update_my_eoi_exitmap()     |
> >  make_all_vcpus_request(update)       |    if (update requested)
> >                                       |
> > ioapic_update_my_eoi_exitmap()
> >  unlock(exitbitmap)                   |
> > The current patch logic is this:
> > 
> > vcpu0 or io thread:                   |      vcpu1:
> > ioapic_write (or other ioapic update) |
> >  lock(exitbitmap)                     |
> >  ioapic_update_all_eoi_exitmaps()     |
> >  make request on each vcpu            |
> >  kick each vcpu                       |     if (update requested)
> >  unlock(exitbitmap)                   |        lock(exitbitmap)
> >                                       |        load_exitbitmap()
> >                                       |        unlock(exitbitmap)
> > If I described correctly what you are proposing I do not
> > see simplification since the bulk of the complexity is in the
> > ioapic_update_(my|all)_eoi_exitmap() and they will be the same in both
> > implementations. Actually I do see complication in your idea introduced
> > by the fact that the case when update is done from vcpu thread have to
> > be handled specially.
> > 
> > The proposed patch may be simplified further by
> > make_all_vcpus_request_async(update)(*) instead of making request and
> > kicking each vcpu individually. In fact the way it is done now is buggy
> > since requests are made only for vcpus with bit set in their bitmask,
> > but if bit is cleared request is not made so vcpu can run with stale
> > bitmask.
> ok, how about the follow logic:
> ioapic_write()
> lock()
> clear_eoi_exitmap_on_all_vcpus()
> perform update(no make request)
> make_all_vcpus_request(like tlb flush)
> unlock()

Why not just 

ioapic writer / map updater context
----------------------------------

ioapic_write()
make_all_vcpus_request()


(no special lock taken)


vcpu context, entry
------------------

	if(check_request(KVM_REQ_, ....)) {
		ioapic_lock();		(*)
		update local EOI exit bitmap from IOAPIC
		ioapic_unlock();
	}



(*) plus any other lock that paths that update the map take





> 
> Best regards,
> Yang

  reply	other threads:[~2013-01-08 13:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-07  2:02 [PATCH v8 0/3] x86, apicv: Add APIC virtualization support Yang Zhang
2013-01-07  2:02 ` [PATCH v8 1/3] x86, apicv: add APICv register " Yang Zhang
2013-01-07  2:02 ` [PATCH v8 2/3] x86, apicv: add virtual interrupt delivery support Yang Zhang
2013-01-07  7:51   ` Gleb Natapov
2013-01-07 13:04     ` Zhang, Yang Z
2013-01-07 13:52   ` Marcelo Tosatti
2013-01-07 17:48     ` Gleb Natapov
2013-01-07 21:32       ` Marcelo Tosatti
2013-01-08  0:43         ` Zhang, Yang Z
2013-01-08 13:40           ` Marcelo Tosatti
2013-01-08 10:03         ` Gleb Natapov
2013-01-08 12:57           ` Zhang, Yang Z
2013-01-08 13:57             ` Marcelo Tosatti [this message]
2013-01-08 15:43               ` Gleb Natapov
2013-01-09  8:07                 ` Zhang, Yang Z
2013-01-09 15:10                   ` Marcelo Tosatti
2013-01-10  0:22                     ` Zhang, Yang Z
2013-01-08 13:53           ` Marcelo Tosatti
2013-01-07  2:02 ` [PATCH v8 3/3] x86, apicv: add virtual x2apic support Yang Zhang
2013-01-07  6:46   ` Gleb Natapov
2013-01-07  6:58     ` Zhang, Yang Z
2013-01-07  7:07       ` 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=20130108135759.GB5121@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox