From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrbEi-0002jY-La for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:06:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrbEg-0002jI-Al for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:06:51 -0400 Received: from [199.232.76.173] (port=36830 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrbEg-0002jB-1J for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:06:50 -0400 Received: from qw-out-1920.google.com ([74.125.92.149]:22969) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LrbEf-0004xJ-JK for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:06:49 -0400 Received: by qw-out-1920.google.com with SMTP id 5so132223qwf.4 for ; Wed, 08 Apr 2009 10:06:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <49DCD8AE.2090007@siemens.com> References: <49DCA2B0.2040509@codemonkey.ws> <5d6222a80904080625k4aa8186fo451772b70509f595@mail.gmail.com> <49DCD212.5050200@siemens.com> <5d6222a80904080941g5b4b9b7lfca2b854caeaf161@mail.gmail.com> <49DCD8AE.2090007@siemens.com> Date: Wed, 8 Apr 2009 14:06:47 -0300 Message-ID: <5d6222a80904081006w65228ac7k3b6e759e08f4c8b3@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: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. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."