[Qemu-devel] QEMU disk geometry sizes

[TSUME]

Hello everybody!

I'm curious why qemu works fine on disk sizes of about 20G, but when I
create 100G sized images it gives a wrong number in BIOS.
When I create a 400G image, the boot screen says my size is.. -11423..MB

When I get freebsd installed, it sees my drive as 400G at first, until I
fsck at boot. Then it changes the drive geometry to 11 TB(I wish)

Is this a bug or does qemu have limitation?

Thank you in advance,
TSUME





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Jim C. Brown wrote:


On Thu, Jul 21, 2005 at 04:00:12PM +0200, Ren? Korthaus wrote:
 

That is what I was also thinking about for some time, but first we  
should then agree on an universal way of saving configurations (this  
was already been touched by the list some time ago, couldnt find the  
mails by now). As I am pretty much satisfied with saving the data in  
an xml file, I would suggest this way, but we shouldnt only focus on  
Mac OS X part, but also on other platforms.


   



I have a shell script that provides config file support for qemu called vqemu.
Basicly the format is a simple "option=value", the shell script sources the
config file in and then passes certain command line options to qemu based on
the options given.

The script should be easy to modify to use on OS X. To make it more portable
(e.g. usable on Windows), converting it to C is not terribly difficult.

 

Right now I'm using .plist(property lists), which is very common in OS 
X, because you can read them back directly in to an Array or a 
Dictionaty. It's a standardized XML File.
I'm a big fan of XML, but I'm also very much Intrested in having a 
compatible package over all platforms.
I see advantage in XML, because it's a lot more flexible and accurat in 
storing your Data - well it was defined exactly for that pourpose :)


My packages look like this:
~/Documents/QEMU/Freedos.qemu/configuration.plist
~/Documents/QEMU/Freedos.qemu/hda.img
~/Documents/QEMU/Freedos.qemu/saved.vm
~/Documents/QEMU/Freedos.qemu/thumbnail.png
or:
~/Documents/QEMU/ReactOS 15412.qemu/configuration.plist
~/Documents/QEMU/ReactOS 15412.qemu/hda.img
~/Documents/QEMU/ReactOS 15412.qemu/saved.vm
~/Documents/QEMU/ReactOS 15412.qemu/thumbnail.png

They can nicely be ziped.

A sample configuration .plist:

"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


   
   -boot
   1
   -cdrom
   
   -fda
   
   -hda
   /Users/mike/Documents/qemu/images/2gb_win2k.img
   -m
   128
   cpu
   0
   custom
   
   name
   win2ksp4
   status
   shutdown
   


I'm also looking into writing a converter for vpc packages, which are 
very similar :)


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Joshua Root wrote:


On 21 Jul 2005, Natalia Portillo <[EMAIL PROTECTED]> wrote:


El 21/07/2005, a las 18:33, Stealth Dave escribió:


On Jul 21, 2005, at 6:46 AM, Hetz Ben Hamo wrote:


On 7/21/05, Mike Kronenberg <[EMAIL PROTECTED]> wrote:


Hetz Ben Hamo wrote:

I'm thinking of a new way to store the images and saved VMs, too.
Maybe we could make something like vpc: A package with the config,
disk-images and saved VMs, located in ~/Documents/QEMU PCs/



Nice idea.



I would recommend ~/Library/QEMU/PCs as an alternative.  OS X tends  
to store all of its program specific configuration information in 
the Library folder, which separates it from actual Documents such  
as disk images, word processor files, images, etc.


Just $0.02 from the Peanut Gallery! :)

- Dave



Yeah but the Library is a obscure place, and VirtualPC for example  
uses Documents with packages inside and I think that is an elegant 
way and also will help deal with old users.
Also VPC uses XML for hardware description and should be easy to 
make  a XML<->XML virtual machine converter, with along qemu-img will 
allow  people to convert old VPC machines to QEMU ones (will be very 
useful  for me).



Besides which, you're not meant to go creating random folders at the 
top level of ~/Library/. If you have a single configuration file, it 
goes in ~/Library/Preferences/, or if you have a collection of things, 
you create a subfolder in ~/Library/Application Support/ and put them 
there.


I would prefer ~/Documents/QEMU/ rather than ~/Library/Application 
Support/QEMU/ since the files stored there will not just be managed 
internally by the app; the user will know about them.


Cheers,
Josh


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


I agree. I used to store the saved VMs in ~/Library/cocoaqemu/. But this 
is no good solution, for if You want to remove qemu, you lose space on 
your HD, if you are not familiar with the library. Exchanging 
preconfigured/saved PC is also a lot easyer, if you have them in a nice 
package at the top of Your Documents Folder


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] pcnet/mingw32 debug info (help needed)

[Christian MICHON]

Apparently, the crash I'm getting is from the tcp/ip layer inside
mingw libs (without debug info). libws2 to be more accurate.
(Maybe it's a slirp/pcnet incompatibility ?)

here's the output of gdb. If anyone can make something from it,
thanks in advance. Pls note I also did a comparison on the
preprocessed output of pcnet.c between linux hosts and
windows host, and htonl calls was the only difference (I
realigned it, but it fails the same way).

==
$ gdb qemu.exe 
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) set args -L . -cdrom slaxpro.iso -nic-pcnet
(gdb) run
Starting program: qemu.exe -L . -cdrom slaxpro.iso -nic-pcnet

Program received signal SIGSEGV, Segmentation fault.
0x77fa5575 in _libws2_32_a_iname ()
(gdb) where
#0  0x77fa5575 in _libws2_32_a_iname ()
#1  0x in ?? ()
==

-- 
Christian


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] 64-bit fixes, this time for Sparc64

[Blue Swirl]

Hi,

Funny, here's a third version of the 64-bit support (among other 
Sparc-related things). With it, Sparc64 system emulator can execute code in 
high memory (>4G) and loads/stores also work.


Fabrice, could you merge the best of all three?

_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


qemu-sparc.patch-38b.bz2
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[René Korthaus]

Am 22.07.2005 um 09:51 schrieb Mike Kronenberg:Jim C. Brown wrote: On Thu, Jul 21, 2005 at 04:00:12PM +0200, Ren? Korthaus wrote:  That is what I was also thinking about for some time, but first we  should then agree on an universal way of saving configurations (this  was already been touched by the list some time ago, couldnt find the  mails by now). As I am pretty much satisfied with saving the data in  an xml file, I would suggest this way, but we shouldnt only focus on  Mac OS X part, but also on other platforms.    I have a shell script that provides config file support for qemu called vqemu.Basicly the format is a simple "option=value", the shell script sources theconfig file in and then passes certain command line options to qemu based onthe options given.The script should be easy to modify to use on OS X. To make it more portable(e.g. usable on Windows), converting it to C is not terribly difficult.  Right now I'm using .plist(property lists), which is very common in OS X, because you can read them back directly in to an Array or a Dictionaty. It's a standardized XML File.I'm a big fan of XML, but I'm also very much Intrested in having a compatible package over all platforms.I see advantage in XML, because it's a lot more flexible and accurat in storing your Data - well it was defined exactly for that pourpose :)Fully agree.My packages look like this:~/Documents/QEMU/Freedos.qemu/configuration.plist~/Documents/QEMU/Freedos.qemu/hda.img~/Documents/QEMU/Freedos.qemu/saved.vm~/Documents/QEMU/Freedos.qemu/thumbnail.pngor:~/Documents/QEMU/ReactOS 15412.qemu/configuration.plist~/Documents/QEMU/ReactOS 15412.qemu/hda.img~/Documents/QEMU/ReactOS 15412.qemu/saved.vm~/Documents/QEMU/ReactOS 15412.qemu/thumbnail.pngWhat about .qvm instead of .qemu ?They can nicely be ziped.A sample configuration .plist:http://www.apple.com/DTDs/PropertyList-1.0.dtd">          -boot       1       -cdrom              -fda              -hda       /Users/mike/Documents/qemu/images/2gb_win2k.img       -m       128       cpu       0       custom              name       win2ksp4       status       shutdown   I assume cpu is the system the image is designed for, f.e. x86? What about some additional keys like author, date of creation, email if someone f.e. downloaded the image from the web and has problems getting it to run?!Hey, FreeOSZoo'ers, what do you think would be also nice to save in the xml regarding distribution on your platform?According to your site:ToDO List:[...]Create a FreeOSZoo hotdelivery XML format, gathering all information needed to download and install FreeOSZoo images. We hope that the FreeOSZoo hotdelivery XML format will allow the next generation of QEMU GUIs to connect to a distribution site and download the needed files automatically. We plan the XML file to deliver the following information:Available mirrors for downloadBittorent trackersHost operating systems requirementsGuest operating systems requirementsList of free software bundledUpgrading facilities over the InternetTargeted audience (home use, ...)Links to a gallery of screenshotsLinks to tutorials and help systemsLinks to live video presentationsI'm also looking into writing a converter for vpc packages, which are very similar :)Very nice! Looking forward to it.Mike___Qemu-devel mailing listQemu-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/qemu-devel ___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: making a raw disk image

[U n d e r a c h i e v e r]

Jim C. Brown <[EMAIL PROTECTED]> wrote:

> On Tue, Jul 19, 2005 at 09:03:32AM +0100, U n d e r a c h i e v e r wrote:
> > 
> > When booting the real hardware, the boot loader is grub IIRC and comes
> > up first, then the NT Boot Loader. Can anyone advise on how to turn
> > /dev/ide/host0/bus0/target0/lun0/part1 into a bootable qemu image? 
> > 
> 
> /dev/ide/host0/bus0/target0/lun0/part1 can be copied into a disk image.
> Thats ot too hard. fdisk -l /dev/ide/host0/bus0/target0/lun0/disk will
> tell you 3 of heads ad #of sectors per track. It will also tell you how
> many cylinders you need for the partition. You can easily create a new
> table on a disk image and dd the partition into the right place.
> 
> However, Windows NT (including 2k and XP) does not like it when you change all
> the hardware (esp. the motherboard & IDE controller). Ok, so how do you get
> Windows to recognize and work with the new hardware (the one that qemu uses) ?
> 
> Short answer: You don't. You can't. You are better off reinstalling win2000
> inside of qemu and then moving all your files from the partition to the disk
> image.
> 
> Long answer: Once installed, Windows has only the minimal drivers required to
> boot the hardware on your computer - which happens to be completely different
> from what qemu emulates. 
> If you really really want to try to set up Windows 2000, try looking at
> http://support.microsoft.com/default.aspx?scid=kb;en-us;314082 and
> http://www.duxcw.com/faq/win/move2K.htm, which explains part of the problem in
> greater detail as well as some possible workarounds. Note that changing
> the drivers for the IDE and motherboard may not be enough - there may be other
> hardware issues as well. (E.g. keep that copy of win2k on the partition until
> you are sure that the copy in the disk image has enough drivers to boot into
> normal mode).

thanks -- whilst that's not exactly the answer I want

oh, to bite the bullet and kills windows then?
-- 
U n d e r a c h i e v e r (and proud)




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

[snip]

Right now I'm using .plist(property lists), which is very common in 
OS X, because you can read them back directly in to an Array or a 
Dictionaty. It's a standardized XML File.
I'm a big fan of XML, but I'm also very much Intrested in having a 
compatible package over all platforms.
I see advantage in XML, because it's a lot more flexible and accurat 
in storing your Data - well it was defined exactly for that pourpose :)



Fully agree.



My packages look like this:
~/Documents/QEMU/Freedos.qemu/configuration.plist
~/Documents/QEMU/Freedos.qemu/hda.img
~/Documents/QEMU/Freedos.qemu/saved.vm
~/Documents/QEMU/Freedos.qemu/thumbnail.png
or:
~/Documents/QEMU/ReactOS 15412.qemu/configuration.plist
~/Documents/QEMU/ReactOS 15412.qemu/hda.img
~/Documents/QEMU/ReactOS 15412.qemu/saved.vm
~/Documents/QEMU/ReactOS 15412.qemu/thumbnail.png



What about .qvm instead of .qemu ?


Ok for me.



They can nicely be ziped.

A sample configuration .plist:

"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


   
   -boot
   1
   -cdrom
   
   -fda
   
   -hda
   /Users/mike/Documents/qemu/images/2gb_win2k.img
   -m
   128
   cpu
   0
   custom
   
   name
   win2ksp4
   status
   shutdown
   




I assume cpu is the system the image is designed for, f.e. 
x86? What about some additional keys like author, date of creation, 
email if someone f.e. downloaded the image from the web and has 
problems getting it to run?!


This is right from Q, so its no real proposal, just to show the 
advantages of xml. cpu stands for the guest PC architekture.


I would propose 4 dicts in a containing dict:
- Description (PC Name, Platform)
- Arguments (with the real qemu arguments)
- Author (FreeOSZoo go go go!)
- Temp (to store temporary "nice to have" hints for a specific port)

Hey, FreeOSZoo'ers, what do you think would be also nice to save in 
the xml regarding distribution on your platform?

According to your site:

ToDO List:
[...]

   1. Create a FreeOSZoo hotdelivery XML format, gathering all
  information needed to download and install FreeOSZoo images. We
  hope that the FreeOSZoo hotdelivery XML format will allow the
  next generation of QEMU GUIs to connect to a distribution site
  and download the needed files automatically. We plan the XML
  file to deliver the following information:
  * Available mirrors for download
  * Bittorent  trackers
  * Host operating systems requirements
  * Guest operating systems requirements
  * List of free software bundled
  * Upgrading facilities over the Internet
  * Targeted audience (home use, ...)
  * Links to a gallery of screenshots
  * Links to tutorials and help systems
  * Links to live video presentations


[snip]

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Pierre d'Herbemont]

On 21 juil. 05, at 15:46, Hetz Ben Hamo wrote:


On 7/21/05, Mike Kronenberg <[EMAIL PROTECTED]> wrote:


Hetz Ben Hamo wrote:



I just looked at the screenshots, and if you don't mind, I want to
offer few suggestions for your GUI:

1. RAM size - how about adding up/down arrows (in addition to  
what you

have right now) to increase RAM?




Good Idea. How should they id/decrement the value? One by one or
doubling the Value?



My suggestion - by 8MB incrememental steps, but allow the user to type
a number in case someone wants type a specific number.


Why a slider, or arrow? A simple text box is far more simpler,  
quicker. Don't tell me that you'll click on the arrow button to get  
256, when you are at 128!





2. Instead of Radio buttons in the Floppy/CDROM/Hard drive, I would
suggest to replace it with Check Boxes, so the ones that are not
needed by the user, will be grayed out until the check boxes will be
marked.



I look into that. Have You an Idea how we could optimize the  
choosing of

cd-rom and cd-rom-image.



Sure. A simple pull down menu instead of the ... circle button, where
you have 2 options:
* Physical Media
* Other (ISO) 

If the user selects Other (ISO) - a sile selection could appear to
select an ISO and then appears. If the user selects "Physical Media" -
the device name appear in the selection.


For the button title why "other". Something like "File" or "CD-ROM  
image" sounds better, more explicit.
And why don't we have an intermediate window that allow the user to  
choose a file or a device, or in the selector you specify if you want  
a device or a file. It may simplify the interface.



I'd like to keep the Panel as easy as possible, so "normal" Users  
won't

be destracted by to much options.
Probably I'm gonna ad '-localtime', '-smb', and
'-user-net'/'-dummy-net', since I activate them by default.



I think Localtime, should also be a checkbox item (in a seperate
line), and user-net / dummy net should be a radio button selection,
but all of them should be hidden until the user press the "Advanced.."
button.


Sounds like a Windows App to me :P No need for Advanced mode, the  
advanced mode sounds scary to me. Keep it simple.
Something like a "Network & File Sharing" section for -smb and -user- 
net. "Time" section for -localtime. If the interface is sufficiently  
explicit and simple no need to hide them, if the names are  
sufficiently user friendly.


This must be discussed a bit, so feel free to reply if you are not  
agree.


BTW, what does Fabrice thinks of having nib files and png in CVS?

Mike, thanks for the work.

Pierre.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] pcnet/mingw32 debug info (help needed)

[Kazu]

Hi,

Sent: Friday, July 22, 2005 4:31 PM Christian MICHON wrote:



here's the output of gdb. If anyone can make something from it,
thanks in advance.


This is a part of  backtrace output of gdb after I set IP address and ping 
10.0.2.2.

I seems that arp packet loops endlessly between pcnet and slirp.
I think something is wrong in pcnet_receive?

#27399 0x004552ac in pcnet_transmit (s=0xcdbf8e8)
   at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:582
#27400 0x00455571 in pcnet_poll (s=0xcdbf8e8)
   at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:625
#27401 0x00454fc3 in pcnet_receive (opaque=0xcdbf8e8, buf=0x22f7b0 "RT",
   size=0) at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:538
#27402 0x004025f7 in slirp_output (pkt=0x22f7b0 "RT", pkt_len=42)
   at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:1402
#27403 0x0045b980 in arp_input (pkt=0xcdbfc30 "??RT", pkt_len=42)
   at C:/msys/1.0/home/kazu/qemu-0.7.0/slirp/slirp.c:583
#27404 0x0045b9dc in slirp_input (pkt=0xcdbfc30 "??RT", pkt_len=42)
   at C:/msys/1.0/home/kazu/qemu-0.7.0/slirp/slirp.c:602
#27405 0x00402611 in slirp_send_packet (nd=0x4e6a90, buf=0xcdbfc30 
"??RT",

   size=42) at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:1411
#27406 0x00402541 in qemu_send_packet (nd=0x4e6a90, buf=0xcdbfc30 
"??RT",

   size=42) at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:1353
#27407 0x004552ac in pcnet_transmit (s=0xcdbf8e8)
   at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:582
#27408 0x00455571 in pcnet_poll (s=0xcdbf8e8)
   at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:625
#27409 0x004556aa in pcnet_poll_timer (opaque=0xcdbf8e8)
   at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:647
#27410 0x00455fa1 in pcnet_ioport_writew (opaque=0xcdbf8e8, addr=49202, 
val=0)

   at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:915
#27411 0x004018f0 in cpu_outw (env=0x3d7358, addr=49202, val=0)
   at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:372
#27412 0x0078456b in code_gen_buffer ()
#27413 0x00404315 in main_loop () at 
C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:2700

#27414 0x00406c94 in main (argc=6, argv=0x3d27e8)
   at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:3719
(gdb) q

This backtrace said that as follows.

cpu_outputw
pcnet_ioport_wirtew <- arp packet is send from pcnet to slirp
pcnet_poll_timer
pcnet_poll
pcnet_transmit

slirp_input
arp_input  <- arp packet returns form slirp to pcnet
slirp_output
pcnet_receive  <- arp packet received by pcnet
pcnet_poll   <- I don't know why pcnet_poll is called again
pcnet_transmit <- endless loop

Regards,
Kazu



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Pierre d'Herbemont wrote:



On 21 juil. 05, at 15:46, Hetz Ben Hamo wrote:


On 7/21/05, Mike Kronenberg <[EMAIL PROTECTED]> wrote:


Hetz Ben Hamo wrote:



I just looked at the screenshots, and if you don't mind, I want to
offer few suggestions for your GUI:

1. RAM size - how about adding up/down arrows (in addition to  what 
you

have right now) to increase RAM?




Good Idea. How should they id/decrement the value? One by one or
doubling the Value?



My suggestion - by 8MB incrememental steps, but allow the user to type
a number in case someone wants type a specific number.



Why a slider, or arrow? A simple text box is far more simpler,  
quicker. Don't tell me that you'll click on the arrow button to get  
256, when you are at 128!


:)




2. Instead of Radio buttons in the Floppy/CDROM/Hard drive, I would
suggest to replace it with Check Boxes, so the ones that are not
needed by the user, will be grayed out until the check boxes will be
marked.



I look into that. Have You an Idea how we could optimize the  
choosing of

cd-rom and cd-rom-image.



Sure. A simple pull down menu instead of the ... circle button, where
you have 2 options:
* Physical Media
* Other (ISO) 

If the user selects Other (ISO) - a sile selection could appear to
select an ISO and then appears. If the user selects "Physical Media" -
the device name appear in the selection.



For the button title why "other". Something like "File" or "CD-ROM  
image" sounds better, more explicit.
And why don't we have an intermediate window that allow the user to  
choose a file or a device, or in the selector you specify if you want  
a device or a file. It may simplify the interface.


Like an NSPopupButon with the options
-CD Rom
-/path/to/file/if/one/was/selected
Separator
-choose an imagefile...

I'd like to keep the Panel as easy as possible, so "normal" Users  
won't

be destracted by to much options.
Probably I'm gonna ad '-localtime', '-smb', and
'-user-net'/'-dummy-net', since I activate them by default.



I think Localtime, should also be a checkbox item (in a seperate
line), and user-net / dummy net should be a radio button selection,
but all of them should be hidden until the user press the "Advanced.."
button.



Sounds like a Windows App to me :P No need for Advanced mode, the  
advanced mode sounds scary to me. Keep it simple.
Something like a "Network & File Sharing" section for -smb and -user- 
net. "Time" section for -localtime. If the interface is sufficiently  
explicit and simple no need to hide them, if the names are  
sufficiently user friendly.


This must be discussed a bit, so feel free to reply if you are not  
agree.


BTW, what does Fabrice thinks of having nib files and png in CVS?


well that would be something I'd like to know, too.
Aktually the nibs are saved as xml. (they are easyer to use until we 
have a form of UI that corresponds to our needs, that could be coded 
directly)
PNGs are not really necessary, the toolbars can be switched to text-only 
mode.


There is another matter, I'd like to discuss:
I've now integrated the controller in the qemu binary, but I dont feel 
happy with that:

1. One can't choose different architectures
2. It's a "oneshot" now (there are things in QEMU that are tied to the 
PID, and there is also a problem with cleaning up with atexit() )


I would preffer a qemu-control (or whatever) that exec()s qemu, 
qemu-x86_64, qemu-ppc as child processes, so they can run in there own 
memory-space.



Mike, thanks for the work.

Pierre. 


Thanks for Your Input.

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] PowerPC64 and more

[J. Mayer]

On Fri, 2005-07-22 at 00:58 +0200, Filip Navara wrote:
> J. Mayer wrote:
> 
> >On Fri, 2005-07-22 at 00:10 +0200, Filip Navara wrote:
> >  
> >
> >>J. Mayer wrote:

[...]
> >>wow, you repeated my and Fabrice's mistake once more ... think about the 
> >>code below more :)
> >>note: when you'll be done thinking or run out of ideas see my x86-64 
> >>patches that i sent to ML this morning.
> >
> >Without this patch, it crashes at the first instruction trying to access
> >the BIOS.
> >And your patch does not solve the problem:
> >on a real PowerPC 64 machine, we can use the whole 64 bits virtual
> >space.
> >We agreed with Fabrice that there should be at least one more
> >indirection in page mapping, because it would cost too much memory to
> >try to map the whole needed memory space in one table, even if we can
> >"forget" some of the middle bits in most cases.
> >  
> >
> Ok, so far so good and I agree with that (I even had the third level of 
> indirection implemented)...
> 
> >Then, you're right, this patch is ugly but allows not to crash until we
> >have a correct solution with indirect tables to get a very large virtual
> >space.
> >
> >  
> >
> ... but read it once more. You're cutting up the "index", not "index >> 
> L2_BITS".

In fact, I did not want to be too invasive outside of target-ppc
subdirectory.
Then I found that Fabrice did a patch in virt_page_find_alloc for x86_64
support
(a few lines above in the same file).
I have to admit I just duplicated this hack and it solved my crashes.
As the address that generated the crash was 0xFFFC (-4), I
just admitted
that it would prevent the crash for any address...
I even did not check if the mask was the right one, in fact...

[...]

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] pcnet/mingw32 debug info (help needed)

[Christian MICHON]

Thx for this report, Kazu

I've a few questions:

1) how did you generate this gdb backtrace ?

2) which gemu guest did you use ?

3) you can apparently set IP address and ping the gateway.
   so your mingw32 compilation of qemu doesn't crash ?
  how did you manage this ? are you using the patch I updated
 or another one, and are you using qemu 0.7.0 or the CVS ?

thx in advance,
Christian

On 7/22/05, Kazu wrote:
> Hi,
> 
> This is a part of  backtrace output of gdb after I set IP address and ping
> 10.0.2.2.
> I seems that arp packet loops endlessly between pcnet and slirp.
> I think something is wrong in pcnet_receive?
> 
> #27399 0x004552ac in pcnet_transmit (s=0xcdbf8e8)
> at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:582
> #27400 0x00455571 in pcnet_poll (s=0xcdbf8e8)


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: making a raw disk image

[André Braga]

2005/7/22, U n d e r a c h i e v e r <[EMAIL PROTECTED]>:
> Jim C. Brown <[EMAIL PROTECTED]> wrote:
> thanks -- whilst that's not exactly the answer I want
> 
> oh, to bite the bullet and kills windows then?

If it's the first partition on the disk, just use dd to copy from the
beginning of the drive up to the last sector of the partition and dump
this on a file. Use that file as a raw image. The relevant part on
number of sectors will be on the MBR. For tidyness, run fdisk on that
image and delete the other partition entries.

If it's not... Then I'm out of ideas :)


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Anyone familiar with the slirp code?

[Paul LeoNerd Evans]

Hi all again,

I'm looking over the slirp code, trying to work out the exact nature of
this AMD64 bug. So far I've determined that some 32bit integer fields
are being used to store struct pointers in - very bad on AMD64 because
pointers are 64 bit. From what I can tell, I can't see how the code
would ever work on any 64 bit machine - can anyone here confirm if this
is indeed the case? What I observe is an immediate segfault of Qemu
itself when the guest OS closes a TCP socket.

What is further confusing me is that I can't find parts of code that
write many of the values; only bits that read them. For example, a
search for anything on the ti_next field gives only the following hits:

./slirp/tcp_input.c:137:q = (struct tcpiphdr *)q->ti_next)
./slirp/tcp_input.c:170:q = (struct tcpiphdr *)(q->ti_next);
./slirp/tcp_input.c:190:q = (struct tcpiphdr *)q->ti_next;
./slirp/tcp_input.c:218:ti = (struct tcpiphdr *)ti->ti_next;
./slirp/tcp_input.c:305:ti->ti_next = ti->ti_prev = 0;
./slirp/tcp_subr.c:87:  n->ti_next = n->ti_prev = 0;
./slirp/tcp_subr.c:170: ti->ti_next = ti->ti_prev = 0;
./slirp/tcp_subr.c:288: t = (struct tcpiphdr *)t->ti_next;
./slirp/tcpip.h:47:#define  ti_next ti_i.ih_next

There are no hits for ih_next directly on its own, other than this macro
define, and some unrelated hits in the udp.c file. I can't see anywhere
where these values are initialised, which leads me to think there must
be something odd going on with different types of struct, and pointers
to them specifically cast about between the types, and members accessed
this way. It seems to me quite a fragile way to work

Is anyone here familiar with the way the code is intended to run..? I
would like to get to the bottom of the issue, and fix it in a proper
robust way...

-- 
Paul "LeoNerd" Evans

[EMAIL PROTECTED]
ICQ# 4135350   |  Registered Linux# 179460
http://www.leonerd.org.uk/


signature.asc
Description: Digital signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: making a raw disk image

[Jim C. Brown]

On Fri, Jul 22, 2005 at 10:16:42AM -0300, Andr? Braga wrote:
> 2005/7/22, U n d e r a c h i e v e r EMAIL HIDDEN:
> > Jim C. Brown did not write:
> > thanks -- whilst that's not exactly the answer I want
> > 
> > oh, to bite the bullet and kills windows then?
> 
> If it's the first partition on the disk, just use dd to copy from the
> beginning of the drive up to the last sector of the partition and dump
> this on a file. Use that file as a raw image. The relevant part on
> number of sectors will be on the MBR. For tidyness, run fdisk on that
> image and delete the other partition entries.
> 
> If it's not... Then I'm out of ideas :)
> 

The technique I gave works perfectly well even if the partition is not the first
one.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Anyone familiar with the slirp code?

[John R. Hogerhuis]

I don't think the original author anticipated or cared about slirp being
ported to a 64-bit processor. I won't speak for the quality of the code
in general, but on a 32-bit machine the pointer size is 32-bit. It's
perfectly safe on that platform to use any 32-bit spot as a hidey hole
for your cookies.

Things like this is why porting from 32-bit to 64-bit is hard. Frankly I
wonder at the reason for increasingly higher word sizes on machines. Is
the bulk of our data these days really 64-bits long? But I digress...

Just go for it. The slirp code was imported into qemu. At this point
you're probably as much an expert as anyone. There is no upstream
maintainer for the code either, I looked and found and asked the last
sucker that had maintained it for a bit, and he just wanted to unload
it.

If you fix it though, be prepared for the fact that you will be the new
expert ;-)

One thing I'd like to see long term is to completely remove the NAT code
and replace it with something more modern and robust like netfilter.
That would give us a lot of nice application level gateways (nat
modules) for important protocols, and some tweakable firewall settings
for user-net.

While I'm wishing, in fact it would be a nice feature in general for
QEMU to have a built in firewall pointed at each host with fairly
minimal permissions by default. A windows machine on your network is a
windows machine on your network, virtual or not :-)

-- John.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Anyone familiar with the slirp code?

[Paul LeoNerd Evans]

On Fri, Jul 22, 2005 at 09:47:13AM -0700, John R. Hogerhuis wrote:
> I don't think the original author anticipated or cared about slirp being
> ported to a 64-bit processor. I won't speak for the quality of the code
> in general, but on a 32-bit machine the pointer size is 32-bit. It's
> perfectly safe on that platform to use any 32-bit spot as a hidey hole
> for your cookies.

Well put.. :)

> Just go for it. The slirp code was imported into qemu. At this point
> you're probably as much an expert as anyone. There is no upstream
> maintainer for the code either, I looked and found and asked the last
> sucker that had maintained it for a bit, and he just wanted to unload
> it.

Well, in this case, it is almost worth pondering if a complete
from-the-top rewrite is required... It might be easiest to look at what
the code is meant to do, from a high level, and re-implement from
scratch. This way, all the required features can be put in from the
beginning, no extra stuff that's not required, and so on... I expect
large amounts of the code can be kept and modified, and the general
layout will remain, but a lot of the data structures will have to
go...

> If you fix it though, be prepared for the fact that you will be the new
> expert ;-)

Hhh I have numerous projects I'm already working on; adding one
more always gets tricky... But we'll see how things pan out...

> One thing I'd like to see long term is to completely remove the NAT code
> and replace it with something more modern and robust like netfilter.
> That would give us a lot of nice application level gateways (nat
> modules) for important protocols, and some tweakable firewall settings
> for user-net.
> 
> While I'm wishing, in fact it would be a nice feature in general for
> QEMU to have a built in firewall pointed at each host with fairly
> minimal permissions by default. A windows machine on your network is a
> windows machine on your network, virtual or not :-)

Well, as I said above, this sort of thing could be implemented with a
re-write

Perhaps we could borrow some of the "iptables" code from the Linux
kernel, and use that..? It would be quite cool, I think, to have
something similar to iptables built into qemu...

-- 
Paul "LeoNerd" Evans

[EMAIL PROTECTED]
ICQ# 4135350   |  Registered Linux# 179460
http://www.leonerd.org.uk/


signature.asc
Description: Digital signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Interesting qemu crash

[Jason Brittain]

I don't know how helpful this will be, but I figured I'd mail it in anyway..

I run qemu repeatedly to test install Linux ISOs.  Just this one time today, it
gave me this text and exited near the end of the anaconda installation of the
guest (Linux):

---
qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a01de

EAX=904c EBX=007f ECX=00155973 EDX=00b3
ESI=004c EDI=ffde EBP= ESP=8ffe
EIP=ffde EFL=0002 [---]CPL=0 II=0 A20=1
ES =9000 0009  
CS =9020 00090200  
SS =9000 0009  
DS =9000 0009  
FS =9000 0009  
GS =9000 0009  
LDT=   8000
TR =   8000
GDT=  
IDT=  
CR0=6010 CR2= CR3= CR4=
CCS= CCD=904c CCO=LOGICB
ST0=-27129.00 ST1=0.00 ST2=0.00 ST3=0.00
ST4=0.00 ST5=0.00 ST6=0.00 ST7=0.00

---

It just did this once.. but I've installed lots of times and have
never seen this
before.

Qemu version: "0.7.0", using kqemu.  I pulled it from CVS and built it.
Host: Fedora Core 2 Linux
Guest: A RedHat 9-ish custom distro with a 2.6 kernel.

I can't investigate it further, but thought I should send the info.

Cheers, and thanks again!

-- 
Jason Brittain


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Anyone familiar with the slirp code?

[Gwenole Beauchesne]

Hi,


From what I can tell, I can't see how the code
would ever work on any 64 bit machine - can anyone here confirm if this
is indeed the case?


AFAICS, slirp code in qemu cvs and other projects works on x86_64. 
Really try CVS instead of 0.7.0. ;-)


Bye,
Gwenolé.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Open Hack'Ware question

[Karel Gardas]

On Thu, 21 Jul 2005, J. Mayer wrote:


On Thu, 2005-07-21 at 17:33 +0200, Karel Gardas wrote:

On Thu, 21 Jul 2005, Jocelyn Mayer wrote:


That would be cool, since this will also help me with booting
RTEMS/PowerPC apps (which are also standard multi-boot elfs)
Unfortunately, I've not been able to come with any patch for this yet...


You should be able to boot an ELF image using -kernel option.
Or it has been broken once again...
I have to check this point.


Could you be so kind and let me know if it works on qemu trunk? There is a
lot of unknown variables in this equation. Perhaps also RTEMS might be
broken, or Qemu don't like RTEMS way of dealing with PPC750/eMesquito
board...


I will check with a kernel Linux for the PREP target.
But it would be great if you give me a link to a small test image so I
may be able to debug this case and keep it to test regressions with
future versions of OHW / Qemu...


Now, I've build mcp750 BSP of RTEMS 4.7 and using this I've build simple 
hello world example. Please consider that I do _not_ have this board so I 
can not verify at all if the example works or not. Anyway, build process 
produced two executables:


silence:~/cvs/rtems/examples/hello_world_c/o-optimize$ file hello.exe
hello.exe: x86 boot sector
silence:~/cvs/rtems/examples/hello_world_c/o-optimize$ file hello.nxe
hello.nxe: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), 
statically linked, not stripped
silence:~/cvs/rtems/examples/hello_world_c/o-optimize$

which is nice since I know even PPC/linux is the `x86 boot sector' file 
type.


For verification that -kernel might be used w/o -hda, I've tried PREP 
linux kernel and it booted well. I haven't had any luck with booting elf 
file `hello.nxe' above, since hackware complain about ``ERROR: Found no 
boot partition''. When I test hello.exe, it at least doesn't complain, but 
also doesn't boot. Now I can see:


Load raw file into memory at 10 160572 (0002733c) 0 ()

at console and when I switch to serial console I even see:

PREP boot... 100200 10
ERROR: BUG caught...
System call exception
nip=0x00100288 msr=0x2030 dar=0x dsisr=0x
Stopping execution


Anyway, you can find all interesting files here:

http://web.iol.cz/kgardas/o-optimize.tar.gz

There is also build.txt containing build log included. You will see that 
hello.exe is really build ala linux way: bootloaded, gziped elf image and 
something else together.


Please let me know if you need anything special. Some RTEMS users already 
promissed to test if RTEMS/mcp750 runs well now, so we will at least know 
that it should work well.


Thanks!
Karel
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] Fix virtual console switching with SDL on Mac OS X

[Christian Walther]

Has switching virtual consoles actually been broken with SDL on non-X11, 
non-win32 platforms (i.e. Mac OS X) for 7 months without anyone noticing 
?? Anyway, here's a patch that fixes it. Just a small change that was 
forgotten in the keymaps support (sdl.c rev. 1.20). Applies to current 
CVS as well as 0.7.0.


 -Christian
Index: sdl.c
===
RCS file: /cvsroot/qemu/qemu/sdl.c,v
retrieving revision 1.21
diff -u -r1.21 sdl.c
--- sdl.c   17 Jan 2005 22:32:23 -  1.21
+++ sdl.c   22 Jul 2005 21:14:11 -
@@ -334,7 +334,11 @@
 gui_key_modifier_pressed = mod_state;
 if (gui_key_modifier_pressed) {
 int keycode;
-keycode = sdl_keyevent_to_keycode(&ev->key);
+if (kbd_layout) {
+keycode = sdl_keyevent_to_keycode_generic(&ev->key);
+} else {
+keycode = sdl_keyevent_to_keycode(&ev->key);
+}
 switch(keycode) {
 case 0x21: /* 'f' key on US keyboard */
 toggle_full_screen(ds);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Anyone familiar with the slirp code?

[Jim C. Brown]

On Fri, Jul 22, 2005 at 08:45:16PM +0200, Gwenole Beauchesne wrote:
> AFAICS, slirp code in qemu cvs and other projects works on x86_64. 
> 
> Bye,
> Gwenol?.
> 

Nope.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Anyone familiar with the slirp code?

[Josh Metzler]

On Friday 22 July 2005 11:51 am, Paul LeoNerd Evans wrote:
> Hi all again,
>
> I'm looking over the slirp code, trying to work out the exact nature of
> this AMD64 bug.
...
> Is anyone here familiar with the way the code is intended to run..? I
> would like to get to the bottom of the issue, and fix it in a proper
> robust way...

You might want to ask the colinux developers, too, as I believe they have 
been doing some work on slirp for their project.

Josh


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] Fix virtual console switching with SDL on Mac OS X

[Jim C. Brown]

On Fri, Jul 22, 2005 at 11:24:21PM +0200, Christian Walther wrote:
> Has switching virtual consoles actually been broken with SDL on non-X11, 
> non-win32 platforms (i.e. Mac OS X) for 7 months without anyone noticing 
> ?? Anyway, here's a patch that fixes it. Just a small change that was 
> forgotten in the keymaps support (sdl.c rev. 1.20). Applies to current 
> CVS as well as 0.7.0.
> 
>  -Christian

Interesting.

Looks like the bug affects X11 and W32 as well, if you are not using a
US keymap.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Anyone familiar with the slirp code?

[Gwenole Beauchesne]

Le samedi, 23 jul 2005, à 00:05 Europe/Paris, Jim C. Brown a écrit :


On Fri, Jul 22, 2005 at 08:45:16PM +0200, Gwenole Beauchesne wrote:

AFAICS, slirp code in qemu cvs and other projects works on x86_64.


Nope.


Then please provide a clear testcase. My testing limited to 32-bit 
Ubuntu Live as guest on 64-bit Mandriva Linux 2005 and downloading 
files from FTP performed very well. The original author of this thread 
was using 0.7.0 and the patch he posted is not enough for 0.7.0 
(SIZEOF_CHAR_P was not defined so sizeof(structure) were bogus).


The current implementation in CVS will work as is on x86_64 because 
dynamically allocated data through malloc() and global data fit under 
32-bit. The former is true because malloc()'ed data is small enough to 
not use mmap() and reside in the data segment. Now, you will get 
crashes if you explicitly set an M_MMAP_THRESHOLD < sizeof(structures 
used in the slirp code).


A more complete solution than used in current CVS can use 
qemu_{malloc,realloc,*}() instead with special provisions to returning 
memory with addresses that fit under 32-bit. qemu already does this but 
only for (deprecated) qemu-fast at this time.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Anyone familiar with the slirp code?

[Jim C. Brown]

On Sat, Jul 23, 2005 at 12:53:55AM +0200, Gwenole Beauchesne wrote:
> Le samedi, 23 jul 2005, ? 00:05 Europe/Paris, Jim C. Brown a ?crit :
> 
> >On Fri, Jul 22, 2005 at 08:45:16PM +0200, Gwenole Beauchesne wrote:
> >>AFAICS, slirp code in qemu cvs and other projects works on x86_64.
> >
> >Nope.
> My testing limited to 32-bit 
> Ubuntu Live as guest on 64-bit Mandriva Linux 2005 and downloading 
> files from FTP performed very well.

Well, I remember someone having issues with slirp and WinXP on an AMD64 host
a few months ago, but you're right that seems to be fixed now.

> 
> Then please provide a clear testcase.

Well, x86_64 on x86_64. But, rereading the emails, that doesn't cover this case,
which is x86 on x86_64.

> A more complete solution than used in current CVS can use 
> qemu_{malloc,realloc,*}() instead with special provisions to returning 
> memory with addresses that fit under 32-bit. qemu already does this but 
> only for (deprecated) qemu-fast at this time.
> 

Still not a very good substitute for fixing the slirp code to handle 64bit
values properly imho.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: making a raw disk image

[André Braga]

2005/7/22, Jim C. Brown <[EMAIL PROTECTED]>:
> The technique I gave works perfectly well even if the partition is not the 
> first
> one.

Oh, I'm sorry, I totally missed it. When he said it was not the answer
he wanted, that somewhat made me skim over your post.

You are absolutely correct. :)


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel