From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49283) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnoRM-0007Vf-Br for qemu-devel@nongnu.org; Mon, 01 Aug 2011 05:05:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QnoRJ-0001yN-ES for qemu-devel@nongnu.org; Mon, 01 Aug 2011 05:05:36 -0400 Received: from david.siemens.de ([192.35.17.14]:21180) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnoRI-0001wm-Nm for qemu-devel@nongnu.org; Mon, 01 Aug 2011 05:05:33 -0400 Message-ID: <4E366C56.90705@siemens.com> Date: Mon, 01 Aug 2011 11:05:26 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1312141678-5141-1-git-send-email-avi@redhat.com> <4E365718.2060500@web.de> <4E365B3A.7050701@web.de> <4E3660C9.3000708@redhat.com> In-Reply-To: <4E3660C9.3000708@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] memory: synchronize dirty bitmap before unmapping a range List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 2011-08-01 10:16, Avi Kivity wrote: > On 08/01/2011 10:52 AM, Jan Kiszka wrote: >> On 2011-08-01 09:34, Jan Kiszka wrote: >> > On 2011-07-31 21:47, Avi Kivity wrote: >> >> When a range is being unmapped, ask accelerators (e.g. kvm) to >> synchronize the >> >> dirty bitmap to avoid losing information forever. >> >> >> >> Fixes grub2 screen update. >> > >> > I does. >> > >> > But something is still broken. As I reported before, the >> performance of >> > grub2 startup is an order of magnitude slower than with the existing >> > code. According to ftrace, we are getting tons of additional >> > EPT_MISCONFIG exits over the 0xA0000 segment. But I haven't spot the >> > difference yet. The effective slot setup as communicated to kvm looks >> > innocent. >> >> I take it back: We obviously once in a while resume the guest with the >> vga segment unmapped. And that, of course, ends up doing mmio instead of >> plain ram accesses. >> > > qemu-kvm.git 6b5956c573 and its predecessor fix the issue (and I think > they're even faster than upstream, but perhaps I'm not objective). > Just updated to the latest memory-region branch - how did you test it? It does not link here due to forgotten rwhandler in Makefile.target. Anyway, that commit has no impact on the issue I'm seeing. I'm also carrying transaction changes for cirrus here, but they have no noticeable impact. That indicates that the new API is not actually slow, it likely just has some bug. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux