From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDFHP-000326-P0 for qemu-devel@nongnu.org; Sun, 07 Jun 2009 06:07:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDFHK-00030x-PK for qemu-devel@nongnu.org; Sun, 07 Jun 2009 06:07:06 -0400 Received: from [199.232.76.173] (port=38481 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDFHJ-00030i-Fy for qemu-devel@nongnu.org; Sun, 07 Jun 2009 06:07:02 -0400 Received: from mx2.redhat.com ([66.187.237.31]:35527) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDFHI-0008HD-Sm for qemu-devel@nongnu.org; Sun, 07 Jun 2009 06:07:01 -0400 Message-ID: <4A2B913B.9070602@redhat.com> Date: Sun, 07 Jun 2009 13:06:51 +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> <4A2B8A4D.3010703@redhat.com> <4A2B8CB5.9040403@web.de> <4A2B8DD4.5060500@redhat.com> <4A2B8EBA.3020402@web.de> In-Reply-To: <4A2B8EBA.3020402@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: > Avi Kivity wrote: > >> Jan Kiszka wrote: >> >>> Avi Kivity wrote: >>> >>> >>>> 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. >>>> >>>> >>>> >>> --- /data/qemu/hw/piix_pci.c 2009-06-07 09:42:27.000000000 +0200 >>> +++ hw/piix_pci.c 2009-06-02 13:00:09.000000000 +0200 >>> ... >>> @@ -91,6 +93,10 @@ static void i440fx_update_memory_mapping >>> int i, r; >>> uint32_t smram, addr; >>> >>> + if (kvm_enabled()) { >>> + /* FIXME: Support remappings and protection changes. */ >>> + return; >>> + } >>> update_pam(d, 0xf0000, 0x100000, (d->config[0x59] >> 4) & 3); >>> for(i = 0; i < 12; i++) { >>> r = (d->config[(i >> 1) + 0x5a] >> ((i & 1) * 4)) & 3; >>> >>> IIRC, this is at least partially due to the restricted slot management >>> in qemu-kvm - or is this obsolete now? >>> >>> >> This is from the first days of qemu-kvm, some of this is due to Intel >> real mode issues (can't start at 0xffff ffff ffff fff0), and some I >> never got around to. It's possible that it requires proper slot >> destruction. Even if that's the case, we cam simply return here, as the >> code shows. >> > > But we can also get past this point as upstream demonstrates (minus > protection changes). > It's actually quite recent: commit d03f4d2defd76f35f46f5418979f3e6d14a11183 Author: Jan Kiszka Date: Wed Sep 10 21:34:44 2008 +0200 I440fx: do change ISA mappings under KVM As long as KVM does not support remapping or protection state changes of guest memory, do not fiddle with the ISA mappings that QEMU see, confusing both the monitor and the gdbstub. Signed-off-by: Jan Kiszka Signed-off-by: Avi Kivity So we can change this to if (kvm_enabled() && kvm_doesnt_support_remapping_or_protection_state_changes()). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.