From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDF3L-0003qq-Do for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:52:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDF3E-0003nk-2r for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:52:32 -0400 Received: from [199.232.76.173] (port=56401 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDF3D-0003nb-UN for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:52:27 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43572) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDF3D-0005j6-Ds for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:52:27 -0400 Message-ID: <4A2B8DD4.5060500@redhat.com> Date: Sun, 07 Jun 2009 12:52:20 +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> In-Reply-To: <4A2B8CB5.9040403@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: >> >>>>> 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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.