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:59:58 +0300 Message-ID: <4FE72B6E.8040900@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> <4FE72838.9070301@redhat.com> <4FE72980.5030807@web.de> <4FE72AA5.5070203@redhat.com> <4FE72B0C.5060908@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]:51955 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753803Ab2FXPAQ (ORCPT ); Sun, 24 Jun 2012 11:00:16 -0400 In-Reply-To: <4FE72B0C.5060908@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 06/24/2012 05:58 PM, Jan Kiszka wrote: >>> Are there really cases where the framebuffer is accessible both via MMIO >>> and RAM-like mappings at the same time? If so, the current flushing on >>> vmexit would help either as the direct mappings would not trigger exits. >>> Or what do you mean? >> >> I meant accesses by the display code to put the framebuffer in front of >> the user's eyes. Those just access the memory directly. We could wrap >> them with memory_region_get/put_ram_ptr() (as Xen requires anyway) and >> have those issue the flush. > > That's a non issue, we already have to flush on display updates. See > e.g. vga_update_display. > Ah, of course. -- error compiling committee.c: too many arguments to function