From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fd8QH-0003UV-8H for qemu-devel@nongnu.org; Mon, 08 May 2006 12:17:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fd8QF-0003UI-Se for qemu-devel@nongnu.org; Mon, 08 May 2006 12:17:24 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fd8QF-0003UF-LO for qemu-devel@nongnu.org; Mon, 08 May 2006 12:17:23 -0400 Received: from [128.8.10.163] (helo=po1.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fd8R7-00087Z-9B for qemu-devel@nongnu.org; Mon, 08 May 2006 12:18:17 -0400 Date: Mon, 8 May 2006 12:17:20 -0400 From: "Jim C. Brown" Subject: Re: [Qemu-devel] bug reports and suggestions Message-ID: <20060508161720.GA17287@jbrown.mylinuxbox.org> References: <20060505215128.4171C1DC197@ravel.n2.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20060505215128.4171C1DC197@ravel.n2.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Don Kitchen Cc: qemu-devel@nongnu.org --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 05, 2006 at 02:51:28PM -0700, Don Kitchen wrote: > $ qemu-img info someimage > image: someimage > file format: qcow > virtual size: 75G (80026361856 bytes) > disk size: 304K > > For files with a backing file, has anyone thought about having it print out > the name of the backing file? Particularly this would be helpful to edit in > the case the backing file is relocated. I'm afraid I have been unable to > locate the correct code for this. Patch attached here. > > Next, it seems the *one* thing QEMU lacks that you-know-who does correctly > is networking, specifically bridged mode. I know about creating a tap device > and sticking it into a bridge (really hasn't worked for me, but that's the > subject for a different day.) I realize that it's a complicated issue > requiring kernel modules, etc, and exponentially more complicated with > cross platform, but I wonder if anyone has considered trying to tie into > the vmware-player's kernel modules and use them? There has to be some sort > of de-facto API for interaction between the modules and the player. Too > rife with IP problems? I'm not sure if vmware-player's modules are documented well enough (assuming they are at all) to do this. I already have an open source kernel module that does this, but it has its own problems. > Now on to the bug reports...Sorry it's in only one email, I thought best > not to blitz many different emails. Uusually that is the best way to get help. ;) > > If I am starting QEMU on a second X server on another VT using this: > xinit qemu ... -full-screen -- :1 > (In this case I am booting windows 2000) and I switch back to :0 *before* > Windoze switches from the splash screen to the light blue background (ie > still booting) X server :1 crashes with the following error: > BadValue (integer parameter out of range for operation) The X server crashes? Are you running Xnest or Xgl or something on :1 ? If its qemu thats crashing with BadValue .. it might be a bug in SDL's fullscreen mode. > > Next, relating to Image size: > > I am creating a large image (320G): > qemu-img create -f raw big.img 312571224 > > but it's only recognized as being 137 GB. By my calculation there are > exactly 37 significant bits. Is this a limitation of the BIOS or qemu? > The only stuff I've found is about an old 2 GB limit. > It is a limit of qemu. IIRC it was a limit of the ATA code (it didn't use 48-bit addressing), though I saw a patch on this list that fixed that. Not sure what happened to it. http://support.octek.com.au/FAQ/faq_0113.htm > Next, relating to the "invisible wall" problem. Sorry I didn't get around to > writing this report earlier, but I have a Mar 25 CVS compile which does not > have this problem and an Apr 21 compile which does. I remember talk about > the tablet stuff about that time but hope this adds a little data to the > issue. > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="qemu-img.c.patch" --- qemu-img.c.orig Mon May 8 12:00:03 2006 +++ qemu-img.c Mon May 8 12:05:58 2006 @@ -22,6 +22,7 @@ * THE SOFTWARE. */ #include "vl.h" +#include "block_int.h" void *get_mmap_addr(unsigned long size) { @@ -665,10 +666,12 @@ printf("image: %s\n" "file format: %s\n" "virtual size: %s (%lld bytes)\n" - "disk size: %s\n", + "disk size: %s\n" + "base image: %s\n", filename, fmt_name, size_buf, (long long) (total_sectors * 512), - dsize_buf); + dsize_buf, + (bs->backing_file[0] != '\0') ? bs->backing_file : "none"); if (bdrv_is_encrypted(bs)) printf("encrypted: yes\n"); bdrv_delete(bs); --u3/rZRmxL6MmkK24--