public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Marcelo Tosatti <mtosatti@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 v8 2/3] x86, apicv: add virtual interrupt delivery support
Date: Tue, 8 Jan 2013 12:03:32 +0200	[thread overview]
Message-ID: <20130108100332.GI21250@redhat.com> (raw)
In-Reply-To: <20130107213239.GB31677@amt.cnet>

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.

(*) not exists yet as far as I see.

--
			Gleb.

  parent reply	other threads:[~2013-01-08 10:03 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 [this message]
2013-01-08 12:57           ` Zhang, Yang Z
2013-01-08 13:57             ` Marcelo Tosatti
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=20130108100332.GI21250@redhat.com \
    --to=gleb@redhat.com \
    --cc=haitao.shan@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.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