Re: [Qemu-devel] bug reports and suggestions

[Jim C. Brown]

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.

qemu-img.c.patch
Description: Text document