From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2 0/7] kvm: Get coalesced MMIO flushing out of the hot-path Date: Thu, 28 Jun 2012 19:09:50 +0300 Message-ID: <4FEC81CE.3010802@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Liu Ping Fan , qemu-devel , kvm , Marcelo Tosatti To: Jan Kiszka Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 06/27/2012 07:27 PM, Jan Kiszka wrote: > Changes in v2: > - added memory_region_clear_flush_coalesced > - call memory_region_clear_flush_coalesced from > memory_region_clear_coalescing > - wrap all region manipulations via memory_region_transaction_begin/ > commit internally > - flush coalesced MMIO only on memory_region_transaction_begin > > Original description: > > We currently flush the coalesced MMIO buffer on every vmexit to > userspace. KVM only provides a single buffer per VM, so a central lock > is required to read from it. This is a contention point given a large > enough VCPU set. Moreover, we need to hold the BQL while replaying the > queued requests, probably for a long time until there is more fine > grained locking available. Good reasons to overcome the unconditional > flush. > > The series achieves this by flushing only on selected memory region > accesses, either generically via the memory access dispatcher or > directly on certain VGA PIO accesses that are not yet fully converted. > Another reason to flush are remappings or other relevant region state > changes. Looks good; please see minor comment on patch 2. -- error compiling committee.c: too many arguments to function