From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDEom-0000Q0-Lp for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:37:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDEoh-0000JC-7F for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:37:31 -0400 Received: from [199.232.76.173] (port=46802 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDEoh-0000Il-2B for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:37:27 -0400 Received: from mx2.redhat.com ([66.187.237.31]:58289) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDEog-00037P-7t for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:37:26 -0400 Message-ID: <4A2B8A4D.3010703@redhat.com> Date: Sun, 07 Jun 2009 12:37:17 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4A26F1E3.1040509@codemonkey.ws> <4A2A92FE.2010700@redhat.com> <4A2AA10B.6060401@web.de> <4A2B49C0.8020703@redhat.com> <4A2B6DD8.3090104@web.de> <4A2B7F5E.8050807@web.de> <4A2B8787.5080603@web.de> In-Reply-To: <4A2B8787.5080603@web.de> Content-Type: text/plain; charset=UTF-8; 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: Blue Swirl , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , "qemu-devel@nongnu.org" Jan Kiszka wrote: >>> >>> Check e.g the diff of hw/vga.c against upstream: All the magic dances >>> there are required as qemu-kvm tracking cpu_register_physical_memory and >>> kvm_log_start cannot cope with all the patterns normal qemu code comes >>> up with. Upstream slot management now provides the same features >>> (including migration) like qemu-kvm, it just does not deal with legacy, >>> thus it does not have to patch qemu code (rather, we were able to remove >>> some already merged hooks - vga_dirty_log_stop). >>> >> Still not very restrictive, all this could be encapsulated with for >> example macro COMPAT_NO_DMRW which could be removed when we don't care >> anymore. Next? >> > > Really, it's not worth the maintenance pain: Every new device emulation > code that wants to be KVM-legacy-compatible would need to be written > like that. And unless you are familiar with the slot management > internals, the "correct" pattern will not be obvious. > Only devices which direct map memory. Currently VGA and cirrus. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.