From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrbWr-0001cC-Nx for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:25:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrbWq-0001bY-MS for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:25:37 -0400 Received: from [199.232.76.173] (port=48858 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrbWp-0001b1-Sl for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:25:35 -0400 Received: from qw-out-1920.google.com ([74.125.92.147]:39628) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LrbWo-0008JL-Vb for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:25:35 -0400 Received: by qw-out-1920.google.com with SMTP id 5so139087qwf.4 for ; Wed, 08 Apr 2009 10:25:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <49DCDCF8.50105@siemens.com> 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> <49DCDCF8.50105@siemens.com> Date: Wed, 8 Apr 2009 14:25:32 -0300 Message-ID: <5d6222a80904081025j1644b6bay17d1ff942247971@mail.gmail.com> Subject: Re: [Qemu-devel] Re: start qemu failed with --enable-kvm -vga std From: Glauber Costa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 On Wed, Apr 8, 2009 at 2:20 PM, Jan Kiszka wrote: > 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. In all seriousness, no matter how good your series for improving kvm registration are, it is unlikely to hit the stable branch. So I believe a good deal would have something on the line of this patch applied to stable, leaving unstable as is, until we can find a better solution. What do you think, anthony? -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."