From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrbSS-0008Ub-Cf for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:21:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrbSN-0008Te-UF for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:21:04 -0400 Received: from [199.232.76.173] (port=38261 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrbSN-0008Ta-Hn for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:20:59 -0400 Received: from gecko.sbs.de ([194.138.37.40]:18890) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LrbSM-0007V5-Us for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:20:59 -0400 Message-ID: <49DCDCF8.50105@siemens.com> Date: Wed, 08 Apr 2009 19:20:56 +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> <49DCD8AE.2090007@siemens.com> <5d6222a80904081006w65228ac7k3b6e759e08f4c8b3@mail.gmail.com> In-Reply-To: <5d6222a80904081006w65228ac7k3b6e759e08f4c8b3@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 2:02 PM, Jan Kiszka wrote: >> 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... >> > > If we can merge the regions, then I agree with you. We'll probably have an > alignment requirement anyway, but it can well be handled in kvm layer. > > However, as you ack yourself, it is likely to take some time. In the mean time, > I believe this fix is acceptable. Unless you're planning on having something > to fix it in the next few days. Easter is coming - if I find my eggs quickly, there might be some time left... ;) I leave the decision up to the maintainers if we should merge this workaround first, or wait a bit longer until we know for sure if we can fix it in a cleaner way. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux