Re: [Qemu-devel] bug reports and suggestions

["Jim C. Brown" <jma5@umd.edu>]

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

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.

[-- Attachment #2: qemu-img.c.patch --]
[-- Type: text/plain, Size: 725 bytes --]

--- 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);