From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDeZ5-0000In-B5 for qemu-devel@nongnu.org; Mon, 08 Jun 2009 09:07:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDeZ0-0000Gc-Bv for qemu-devel@nongnu.org; Mon, 08 Jun 2009 09:07:02 -0400 Received: from [199.232.76.173] (port=39366 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDeZ0-0000GX-95 for qemu-devel@nongnu.org; Mon, 08 Jun 2009 09:06:58 -0400 Received: from mx2.redhat.com ([66.187.237.31]:34981) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDeYy-0001uH-Ha for qemu-devel@nongnu.org; Mon, 08 Jun 2009 09:06:56 -0400 Message-ID: <4A2D0CE4.9080405@redhat.com> Date: Mon, 08 Jun 2009 16:06:44 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4A26F1E3.1040509@codemonkey.ws> <4A27FC69.9070501@mayc.ru> <20090605201415.GA22847@csclub.uwaterloo.ca> <20090608001312.GE15426@shareable.org> <4A2CA8C2.2080004@redhat.com> <20090608115755.GD25684@shareable.org> <4A2CFE07.90700@redhat.com> <20090608121626.GF25684@shareable.org> <4A2D03E7.8070702@redhat.com> <4A2D07A3.8090101@siemens.com> In-Reply-To: <4A2D07A3.8090101@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: POLL: Why do you use kqemu? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anton D Kachalov , "qemu-devel@nongnu.org" , Lennart Sorensen Jan Kiszka wrote: > And the fact that kqemu has to use tcg in order to achieve a reasonable > performance is rather a disadvantage. The complexity and overhead for > synchronizing tcg with the in-kernel accelerator is enormous. If there > were a feasible way to overcome this with kqemu, it would benefit a lot. > But unfortunately there is none (given you don't want to invest > reasonable efforts). > Note that kvm suffers from something similar (to a smaller magnitude) as well: if a guest pages in its page tables, kvm knows nothing about it and will thus have outdated shadows. To date we haven't encountered a problem with it, but it's conceivable. I think Windows can page its page tables, but maybe it's disabled by default, or maybe it doesn't dma directly into the page tables. Not sure how to fix. Maybe write protect the host page tables when we shadow a page table, and get an mmu notifier to tell us when its made writable? Seems expensive. Burying head in sand is much easier. -- error compiling committee.c: too many arguments to function