From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] kvm: First step to push iothread lock out of inner run loop Date: Sun, 24 Jun 2012 17:46:16 +0300 Message-ID: <4FE72838.9070301@redhat.com> References: <4FE4F56D.1020201@web.de> <4FE4F7F5.7030400@web.de> <20120623002259.GA13440@amt.cnet> <20120623090646.GA21908@amt.cnet> <4FE5AC75.1020504@web.de> <4FE71F71.7030908@web.de> <4FE7259F.4030100@redhat.com> <4FE726CF.5090906@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: liu ping fan , Marcelo Tosatti , qemu-devel , Liu Ping Fan , Alexander Graf , Anthony Liguori , kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:64327 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752815Ab2FXOqz (ORCPT ); Sun, 24 Jun 2012 10:46:55 -0400 In-Reply-To: <4FE726CF.5090906@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 06/24/2012 05:40 PM, Jan Kiszka wrote: > On 2012-06-24 16:35, Avi Kivity wrote: >> On 06/24/2012 05:08 PM, Jan Kiszka wrote: >>> As a first step, I will post a series later that gets rid of >>> kvm_flush_coalesced_mmio_buffer in the common vmexit path. >> >> If you defer this, I can think of two places that need to flush: >> - anything that accesses those memory areas (such as DMA to the >> framebuffer, or updating the display) > > - anything that accesses related areas (in case of VGA: PIO accesses to > the control ports). I'm providing memory_region_set_flush_coalesced that > allows to flush on non-coalesced region accesses as well. Some PIO > accesses unfortunately still need open-coded > qemu_flush_coalesced_mmio_buffer as they do not use memory regions yet. Framebuffer access will bypass the MemoryRegionOps callbacks, did you intend to hook those? I'm not sure the problem is general enough to merit a check in our generic mmio dispatch code (granted, now it has a check in the vcpu exit path which is much worse). -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sio5X-0006Jq-N1 for qemu-devel@nongnu.org; Sun, 24 Jun 2012 10:46:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sio5W-0004zF-0Z for qemu-devel@nongnu.org; Sun, 24 Jun 2012 10:46:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sio5V-0004zA-Ol for qemu-devel@nongnu.org; Sun, 24 Jun 2012 10:46:53 -0400 Message-ID: <4FE72838.9070301@redhat.com> Date: Sun, 24 Jun 2012 17:46:16 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4FE4F56D.1020201@web.de> <4FE4F7F5.7030400@web.de> <20120623002259.GA13440@amt.cnet> <20120623090646.GA21908@amt.cnet> <4FE5AC75.1020504@web.de> <4FE71F71.7030908@web.de> <4FE7259F.4030100@redhat.com> <4FE726CF.5090906@web.de> In-Reply-To: <4FE726CF.5090906@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Liu Ping Fan , kvm , qemu-devel , Marcelo Tosatti , Alexander Graf , liu ping fan , Anthony Liguori On 06/24/2012 05:40 PM, Jan Kiszka wrote: > On 2012-06-24 16:35, Avi Kivity wrote: >> On 06/24/2012 05:08 PM, Jan Kiszka wrote: >>> As a first step, I will post a series later that gets rid of >>> kvm_flush_coalesced_mmio_buffer in the common vmexit path. >> >> If you defer this, I can think of two places that need to flush: >> - anything that accesses those memory areas (such as DMA to the >> framebuffer, or updating the display) > > - anything that accesses related areas (in case of VGA: PIO accesses to > the control ports). I'm providing memory_region_set_flush_coalesced that > allows to flush on non-coalesced region accesses as well. Some PIO > accesses unfortunately still need open-coded > qemu_flush_coalesced_mmio_buffer as they do not use memory regions yet. Framebuffer access will bypass the MemoryRegionOps callbacks, did you intend to hook those? I'm not sure the problem is general enough to merit a check in our generic mmio dispatch code (granted, now it has a check in the vcpu exit path which is much worse). -- error compiling committee.c: too many arguments to function