From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrbAk-0001gU-Bu for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:02:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrbAf-0001cg-Op for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:02:45 -0400 Received: from [199.232.76.173] (port=36739 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrbAf-0001cX-Fk for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:02:41 -0400 Received: from gecko.sbs.de ([194.138.37.40]:16970) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LrbAe-0004JE-Nk for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:02:41 -0400 Message-ID: <49DCD8AE.2090007@siemens.com> Date: Wed, 08 Apr 2009 19:02:38 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <49DCA2B0.2040509@codemonkey.ws> <5d6222a80904080625k4aa8186fo451772b70509f595@mail.gmail.com> <49DCD212.5050200@siemens.com> <5d6222a80904080941g5b4b9b7lfca2b854caeaf161@mail.gmail.com> In-Reply-To: <5d6222a80904080941g5b4b9b7lfca2b854caeaf161@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: start qemu failed with --enable-kvm -vga std Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Glauber Costa Glauber Costa wrote: > On Wed, Apr 8, 2009 at 1:34 PM, Jan Kiszka wrote: >> Glauber Costa wrote: >>> On Wed, Apr 8, 2009 at 10:12 AM, Anthony Liguori wrote: >>>> Peng Huang wrote: >>>>> Hi, >>>>> >>>>> The HEAD version qemu can not execute a VM with --enable-kvm -vga std or >>>>> -vga vmware on kernel 2.6.29.1-46.fc11.x86_64. I found it is because of qemu >>>>> call cpu_register_physical_memory with a wrong size. Below patch can fix it >>>>> on my box. Please test it. >>>> Glauber came up with a similar patch for kvm-userspace and is currently >>>> attempting to root cause the issue. >>> I believe this is in fact the root cause. KVM slot management code >>> probably require >>> memory to be page aligned. By trying to register a region that is not >>> page aligned, >>> the ioctl may fail. I, however, did not see this happening in qemu >>> upstream (only kvm-userspace), >>> and have absolutely no idea about why. But the patch makes perfect sense to me. >>> >> But this really sounds like a limitation that should better be fixed in >> the kvm layer, not the device/machine code. >> >> We only map ROM regions here. So rounding them up/down and sending >> properly aligned requests to the kernel should finally have the same >> result for all involved pages. Only if non-compatible regions overlap >> due to such roundings, we should bail out - and start to consider >> changing device code. > > I've considered this, but then the alignment constraints become implicit, > rather than explicit. Consider the option rom registration code itself. > > We should start loading option roms right after vga. If kvm layer Unless I misread something, this is about option ROMs after VGA ROM. > aligns the region > implicitly, then where will option roms start? At better, we would have to tell > qemu back that such an alignment were made, to start looking for option > roms in the right place. > My ideas is to merge both ROM regions (given we are actually talking about compatible stuff here): the 2k VGA ROM would first be expanded to 4k, then the next option ROM starting after the VGA would extend the latter. But that's plain theory so far. > I believe being explicit, and requiring page alignment is safer, and > does not hurt. In this case, we would waste 2k of (sometimes) precious low mem... Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux