Re: [Qemu-devel] High CPU Usage with Linux 2.6.24 and Windows XP Guest (but not with 2.6.23)
On 3/9/08, Steve Fosdick [EMAIL PROTECTED] wrote: I have found a single config change that causes the problem. With: # CONFIG_HIGH_RES_TIMERS is not set kqemu works correctly, whereas with: CONFIG_HIGH_RES_TIMERS=y the problem appears. Any idea why that causes a problem? Is it a bug? Anyway, at least for now I have a solution. Thanks for your help. you're welcome. keep in mind it's good to have a portable config between kernels. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] High CPU Usage with Linux 2.6.24 and Windows XP Guest (but not with 2.6.23)
On Thu, Mar 6, 2008 at 3:31 PM, Steve Fosdick [EMAIL PROTECTED] wrote: So, the compiler appear to be the same basic version of gcc, but slightly different build. I will try recompiling the 2.6.23 kernel with the latest compiler to see if the problem then occurs. ok Regarding the kernel config itself, I attach the two config files and the output of diff -u. it's really a lot of differences... could you find a minimal kernel config (which could be almost identical for 2.6.23 and 2.6.24) showing the slowdown? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] High CPU Usage with Linux 2.6.24 and Windows XP Guest (but not with 2.6.23)
On Thu, Mar 6, 2008 at 11:58 AM, Steve Fosdick [EMAIL PROTECTED] wrote: The hardware is an AMD64 processor and 1GB RAM. The problem with 2.6.24 seems only to occur with kqemu and also appears in dependant of whether dynamic ticks is enabled. A couple of timings should illustrate the difference. From VM start to login prompt: no kqemu=2m0s, 2.6.23=1m2s, 2.6.24=1m27s. From login to last systray icon: no kqemu=6m25s, 2.6.23=1m47s, 2.6.24=4m46s Does anyone have any insight as to what may be happening or what tools I could use to gather enough information to help you guys diagnose the problem? did you compile both kernels yourself, with similar/compatible config/compilers ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
[Qemu-devel] ANN: DetaolB v0.8.1 is released
DetaolB v0.8.1 has been released 26th,January 2008 http://prdownloads.sf.net/detaolb/detaolb_v081.iso (~60Mb) This is a bug fix release mostly. The website will soon be updated. Changelog: - fixed NumLock issues for fvwm2 - fixed segfaults of fdisk in busybox-1.9.0 - fixed SciTE editor for standard user - tweak openssl for Dillo - Dillo can now access gmail.com - added git-cvsimport capability - added readline Thanks for the feedbacks and the beta testers :-) PROGRESS, BUGS, SUGGESTIONS: [EMAIL PROTECTED] -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
[Qemu-devel] ANN: DetaolB v0.8 is released
DetaolB v0.8 has been released 18th,January 2008 http://prdownloads.sf.net/detaolb/detaolb_v08.iso (~60Mb) Changelog: - added debugging capabilities (gdb, ddd) - added fortran language support - added many editors (qemacs, Scite, nedit, zile) - upgrade to perl 5.10 ! - static checker for c/c++ (splint) and fortran (ftncheck) This distro works very well on real hardware (you can customize the kernel and iso as you wish). It's mostly dedicated to qemu 0.9.0 or virtualbox 1.5.4 (they fix the display bug: yeah!). Network starts automatically if the host is properly connected to internet with these 2 emulators! You can play with the grub menu (press the key 'e') at boot sequence and choose the framebuffer resolution you want using the screen parameter (example: screen=vga or screen=svga or screen=xga or screen=sxga). You can choose a french keyboard by using the kmap parameter (kmap=fr) or stick to the us default. There will be more keyboard maps soon. We're getting very close to a 1.0 release: hopefully we'll finished being listed at http://distrowatch.org. Thanks for the feedbacks and the beta testers :-) PROGRESS, BUGS, SUGGESTIONS: [EMAIL PROTECTED] -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] QEMU version 0.9.1
On Jan 6, 2008 11:03 PM, Fabrice Bellard [EMAIL PROTECTED] wrote: Hi, QEMU version 0.9.1 is out ! You can get it from: http://bellard.org/qemu/download.html . Fabrice. working great on WinXP as host, using or not kqemu. thanks and have a good year ahead! -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
[Qemu-devel] ANN: DetaolB v0.7.1 is released
a bugfix release for DetaolB v0.7 is available at: http://downloads.sf.net/detaolb/detaolb_v071.iso Changelog: - tinycc binaries were actually missing (sorry Rob! fixed!) - mp small editor added (real name is mped, with color highlighting: really small footprint!) - xorg-dev is added for those who want to compile x11 apps :-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
[Qemu-devel] ANN: DetaolB v0.7 is released
DetaolB v0.7 has been released 22nd,December 2007 http://prdownloads.sf.net/detaolb/detaolb_v07.iso (~48Mb) DetaolB is a small size x86/uclibc distro, aimed mostly for emulators/virtualizers (like qemu). It also runs on real hardware and can be used on a bootable usb key (mandriva flash like). Changelog: - c++ is now fully supported (this is what took most of the time) - migration to uvesafb (works fine now on real hardware!) - iso boots now using grub4dos (this is needed for usb boot) - x11r72 was completely rebuilt (x11r73 does not work yet) - rox file manager added - possible to create a bootable usb key (I need to write a tutorial on this) - network is supported inside a qemu guest: you still need to perform once udhcpc - Rob Landley's fork of tinycc is back! - dillo can be used for surfing once network is enabled - many packages updated to the latest (like git vim) - CREDITS added (thanks to contributors!) - foreign/custom keyboards will be in next release (sorry!) As of today, it's now possible to compile big complex c++ software like firefox 2.0.0.11 ;-) [but you need xorg-dev to compile x11 apps: I kept it for next release] Yet, I feel this is too big to make it inside the standard iso: the firefox squashfs is about 10Mb... I'll let vox populi decide if you want it in the next release or not. xorg-dev is about 3Mb, so it will be available soon. Looking forward to get feedback on this iso and to get a wishlist for next release. PROGRESS, BUGS, SUGGESTIONS: [EMAIL PROTECTED] Last, but not least: Merry Xmas and Happy New Year to all 3 mailing lists subscribers! -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] Kernel panic - not syncing: No init found. Trypassing init= option to kernel.
On 10/19/07, Kjel Delaey [EMAIL PROTECTED] wrote: I came home and I tried the stuff at my desktop (I was in school in the morning). I followed your steps Christian and I have also downloaded the detaolb_v06.iso file. I have also changed the line in .config. I have extracted debug in my working directory. If I use debug I have the following message: /bin/sh: can't access tty: job control turned off. By the way, thank you all for helping me out :) I'm trying since 8.30 am. It must work ;) (init problem/solved!) qemu -m 32 -hda rootfs.img -kernel linux-2.6.18.1/arch/i386/boot/bzImage -append root=/dev/hda \clock=pit (tty problem) qemu -m 32 -hda rootfs.img -kernel linux-2.6.18.1/arch/i386/boot/bzImage -initrd debug -append root=/dev/hda \clock=pit Turning off tty in busybox isn't a working solution. I couldn't send an email earlier because I had problems with Hotmail. it's normal. debug is where the first process is actually a shell. you need to boot on an initramfs that contains proper runlevel 3 and login utils. Please download detaolb_v01.iso and extract initrmfs.v01. This should do! -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] Kernel panic - not syncing: No init found. Trypassing init= option to kernel.
Kjel, I managed to compile the kernel with your config file and the vanilla linux 2.6.18.1. With the debug initramfs from DetaolB, I get similar error messages. I enabled only CONFIG_BLK_DEV_INITRD=y and the problem was gone. Could you please try this ? I can send you separately (off list) the debug file. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] Kernel panic - not syncing: No init found.
On 10/19/07, Kjel Delaey [EMAIL PROTECTED] wrote: I can't find the initramfs file. When I use locate initramfs I can find some initramfs files, but none in the directory where I work in. From: [EMAIL PROTECTED] To: qemu-devel@nongnu.org Subject: Re: RE: [Qemu-devel] Kernel panic - not syncing: No init found. Date: Fri, 19 Oct 2007 11:04:07 +0200 are you passing an initrd to qemu? i call qemu like this: qemu \ -hda image \ -boot c \ -net user \ -net nic,vlan=0,model=rtl8139 \ -initrd initrd \ -append root=/dev/hda1 \ -kernel kernel \ -no-kqemu whereas kernel is a link to the bzImage and initrd links to a file i have created inside qemu using mkinitramfs Clemens On Friday 19 October 2007 10:54:58 [EMAIL PROTECTED] wrote: If I do this I got a VFS problem Not syncing: VFS: Unable to mount root fs on unknown-block(3,1.) I also tried to enable reiserfs support. I read on a forum that this may be a solution to the init problem. In my case it wasn't a working solution. From: [EMAIL PROTECTED] To: qemu-devel@nongnu.org; [EMAIL PROTECTED] Subject: Re:[Qemu-devel] Kernel panic - not syncing: No init found. Trypassinginit= option to kernel. Date: Fri, 19 Oct 2007 09:19:59 +0200 CC: On Friday 19 October 2007 09:13:40 [EMAIL PROTECTED] wrote: Then I try this command: qemu -m 32 hda rootfs.img kernel linux-2.6.18.1/arch/i386/boot/bzImage -append root=/dev/hda \clock=pit and I get the error... I tried to pass init=/sbin/init or init=/bin/init but it doesn't help... Hi! Although allmost every documentation tells you to use exactly what you did, I always use qemu [] -append root=/dev/hda1 (note HDA1 instead HDA) and direct booting works fine for me :-) Clemens Deel al je foto's met je vrienden! Maak je eigen online plek! Windows Live Spaces you need to generate this file. may I suggest something (while I do it in parallel) ? please download detaolb_v06.iso and extract the debug file at the root of the iso. This is a static initramfs file. Use it this way: qemu -L bios -hda hda -kernel vmlinux -initrd debug you can find the iso at http://detaolb.sf.net On my side, I'll compile linux 2.6.18.1 with your config file and test it over here... -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] Kernel panic - not syncing: No init found. Trypassing init= option to kernel.
try to turn on these: CONFIG_BLK_DEV_INITRD=y CONFIG_BLOCK=y CONFIG_PROC_SYSCTL=y (this one may not be valid for 2.6.18*) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] Kernel panic - not syncing: No init found. Trypassing init= option to kernel.
On 10/19/07, Kjel Delaey [EMAIL PROTECTED] wrote: If I do this I got a VFS problem Not syncing: VFS: Unable to mount root fs on unknown-block(3,1.) then maybe it's a kernel config issue. it may not be only fs dependent. do you have the .config file ? I also tried to enable reiserfs support. I read on a forum that this may be a solution to the init problem. In my case it wasn't a working solution. From: [EMAIL PROTECTED] To: qemu-devel@nongnu.org; [EMAIL PROTECTED] Subject: Re:[Qemu-devel] Kernel panic - not syncing: No init found. Trypassing init= option to kernel. Date: Fri, 19 Oct 2007 09:19:59 +0200 CC: On Friday 19 October 2007 09:13:40 [EMAIL PROTECTED] wrote: Then I try this command: qemu -m 32 hda rootfs.img kernel linux-2.6.18.1/arch/i386/boot/bzImage -append root=/dev/hda \clock=pit and I get the error... I tried to pass init=/sbin/init or init=/bin/init but it doesn't help... Hi! Although allmost every documentation tells you to use exactly what you did, I always use qemu [] -append root=/dev/hda1 (note HDA1 instead HDA) and direct booting works fine for me :-) Clemens Start vandaag nog je eigen Windows Live Space en deel je leven met je vrienden Windows Live Spaces -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] qemu Changelog aes.c arm-dis.c arm-semi.c block...
On 9/17/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Log message: find -type f | xargs sed -i 's/[\t ]*$//g' # Yes, again. Note the star in the regex. so you're going to do this each time you receive a faulty patch ? I thought this kind of search and replace is more likely to happen when cleaning up just before release. is qemu-0.9.1 going to be reached anytime soon then ? ;-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On 9/17/07, J. Mayer [EMAIL PROTECTED] wrote: Log message: find -type f | xargs sed -i 's/[\t ]$//g' # on most files Many thanks for generating hundreds of conflicts with a useless commit. Don't know what's wrong in your expression but it did not what you think it should (and you did not even check). DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... git-apply indead has this feature about ignoring useless whitespaces... -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote: DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... Maybe... but Savannah uses a CVS frontend, as far as I know... Those are excuses. So is a you should have used X argument. It doesn't invalidate the point that the commit was disruptive, and merely acts as bait for the grand old version repository flamewar.* since I mentionned you should have used Git, I'll repeat: this commit was not disruptive to any of the Git users, and will never be. Evolve, or prepare to be assimilated into the Collective... ;-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
On 9/17/07, Andreas Färber [EMAIL PROTECTED] wrote: Evolve, or prepare to be assimilated into the Collective... Both the qemu.org and the Savannah project page only mention CVS. If there are better ways to get the code then inform your users how to use that. Writing only of CVS and then telling people they should have used git instead is pure nonsense. it's been more than a year since I turned my back to CVS. I do not recall writing only of CVS. What I said was: if we were using Git, we would not face these merge conflicts. You can point to git copies of the CVS qemu repository, or perform yourself the import. You can even push your modification into the CVS vault using Git. If this is not clear to you, see this link: http://www.youtube.com/watch?v=4XpnKHJAok8 Sticking with CVS is pure nonsense. Period. Face reality; this is not some science-fiction movie. You should face reality. Linux kernel, Xorg, KDE and soon Gnome made the move over to Git. It was a sci-fi joke, by the way: I put a smiley behind it. Einsverstanden ? ;-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] about NICs
On 9/14/07, Mike Swanson [EMAIL PROTECTED] wrote: On Friday 14 September 2007 12:07:35 Sebastien WILLEMIJNS wrote: hi, i noticed ubuntu LiveCD 7.04 QEMU emulation now only works with RTL8139 NICs (because NE2K drivers seems has been deleted from ISO) i'm not surprised because they are no standard in facto as SB for sound and SVGA for graphic but i'd like in the future adding some new NIC ROM if RTL8139 will be not available in ubuntu... Honestly, I thought that NE2000 *was* the de facto standard :P Really ? Look at the other virtualizers/emulators: Realtek RTL8139 is the standard eth0 for MS VirtualPC 2007 I have not checked Parallels for ages but I believe it was the case too. Does it matter ? You can always recompile the module needed and add it to ubuntu (you may need to modify the iso). I'll release soon DetaolB v0.7: it's a live CD, it may not be as big as Ubuntu, but in this next release, network using eth0 ne2k works and you'll be able to use network out-of-the-box if used inside qemu. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Re: [Qemu-devel] KQEMU build on MinGW patch
On 9/8/07, Filip Navara [EMAIL PROTECTED] wrote: Attached patch allows KQEMU to build on pure MinGW installation without the need for ELF tools or compilation on Linux. I'm not sure if it breaks the Linux compilation, so it should be carefully tested. Hope it's usefull at least for someone. at long last!... I thought it was my setup that was wrong, so I've always used the supplied kqemu.sys. Now only I realize we're supposed to cross compile. yes, it's very useful ! and it works :) Thanks! -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
[Qemu-devel] ANN: DetaolB v0.6 is released
DetaolB is a small size x86/uclibc distro, aimed mostly for emulators/virtualizers. With this iso's size around 40Mb, you've a small yet functional desktop distro which can help developping C software or compiling the linux kernel. It can then self emulate with included qemu-0.9.0 ;-) DetaolB v0.6 has been released 26,August 2007 on sf.net = http://detaolb.sf.net Changelog: - re-shuffled the barebone system - this is a multi-user iso now with 2 logins: root and neo - updated git and vim - added some asm tools and binary editor - vesafb-tng is still in use (uvesafb is having problems on real hardware - added liveusb switch to kernel parameters - added qemu-0.9.0 with kqemu (all you need to do: insmod `find /lib -name *.ko` ) This distro works in qemu, vmplayer, virtualpc 2007 and some real hardware... You can copy on a FAT32 formatted usb key the modules subdirectory from the iso, boot from the iso and add liveusb to the graphical resolution you want to boot in. This allows to add/remove/upgrade the modules on the usb key (no need to burn more cdroms) Detailed list of modules: barebone: - barebone-0.6 - busybox-1.6.1 - bzip2-1.0.4 - coreutils-6.9 (lite) - cpio-2.8 - diffutils-2.8.1 - e2fsprogs-1.40 - findutils-4.2.31 - gzip-1.3.12 - htop-0.6.6 - less-382 - ncurses-5.6 - tar-1.18 - uclibc-0.9.29 - zlib-1.2.3 editor: - bvi-1.3.2 - vim-7.1.85 interpreter: - gawk-3.1.5 - perl-5.8.8 - tcl-8.4.15 qemu: - kqemu-1.3.0pre11 - qemu-0.9.0 - SDL-1.2.8 scm: - git-1.5.2.5 toolchain: - ald-0.1.7 - bash-3.2 - binutils-2.16.1 - bison-2.1 - flex-2.5.33 - gcc-3.4.6 - headers-2.6.22 - m4-1.4 - make-3.81 - nasm-0.98.39 - patch-2.5.4 x11: - some x11 fonts - fvwm-2.4.20 - glib-1.2.10 - gtk+-1.2.10 - gvim-7.1 - libjpeg.62 - mrxvt-0.5.2 - tk-8.4.15 - xorg-7.2 (lite) PROGRESS, BUGS, SUGGESTIONS: [EMAIL PROTECTED] -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
[Qemu-devel] [optional patch] in order to compile qemu-0.9.0 for uclibc-0.9.29
Hi lists, for those who would optionally need qemu-0.9.0 (not the CVS current, the official release) compiled versus uclibc-0.9.29 on x86, please find attached a patch which allows it. i've not tested other architectures like arm/sparc. it's basically a removal of aio (not present in uclibc) and of floatx80 math operations (not all available in uclibc). this is optional: your mileage may vary. the cool thing about it is that next release of detaolb 0.6 will include qemu binaries. kqemu works too if you compile it yourself for detaolb. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu qemu-0.9.0-uclibc.patch Description: Binary data
[Qemu-devel] Re: ANN: DetaolB v0.5 is released
On 8/21/07, Rob Landley [EMAIL PROTECTED] wrote: On Friday 17 August 2007 3:23:04 pm Christian MICHON wrote: DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. As did Puppy Linux before it. Rob I actually intend to keep uclibc at least, and later on propose, like slax, different types of iso/editions. If your tcc fork can compile the kernel, uclibc, I'll gladly remove binutils and gcc :) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
[Qemu-devel] ANN: DetaolB v0.5 is released
DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. In less than 40Mb, you've a small yet functional desktop distro which can help developping software or compiling the linux kernel. DetaolB v0.5 has been released 17th,August 2007 on sf.net = http://sourceforge.net/project/showfiles.php?group_id=140321package_id=155481release_id=528334 Changelog: == - removed lzma patch (I've problems making a working c++ uclibc compiler) - upgraded to linux-2.6.22 + SLUB, tickless, aufs 20070813 and squashfs 20070805 - added perl, tcltk modules - upgraded to busybox-1.6.1, xorg/kdrive r7.2 - improved boot menu: still log in as root, then xinit - vesafb-tng allows to change the resolution of the framebuffer without rebooting :) - patches are included in the iso This distro works in qemu, vmplayer, virtualpc 2007 and some real hardware... It also boot in colinux with a 2.6.17 special kernel. A USB port is on the way... !! It does not work with VirtualBox: bug #512 has been filed. !! Please report progress, bug, suggestions to this Mailing list: [EMAIL PROTECTED] Detailed list of modules: = barebone: busybox-1.6.1 bzip2-1.0.4 coreutils-6.9 (lite) cpio-2.8 diffutils-2.8.1 e2fsprogs-1.40 findutils-4.2.31 gzip-1.3.12 htop-0.6.6 less-382 ncurses-5.6 tar-1.18 uclibc-0.9.29 zlib-1.2.3 editor: vim-7.1 interpreter: gawk-3.1.5 perl-5.8.8 tcl-8.4.15 scm: git-1.5.2.3 toolchain: bash-3.2 binutils-2.16.1 bison-2.1 flex-2.5.33 gcc-3.4.6 headers-2.6.21 (to be changed soon) m4-1.4 make-3.81 patch-2.5.4 x11: some x11 fonts fvwm-2.4.20 glib-1.2.10 gtk+-1.2.10 gvim-7.1 libjpeg.62 mrxvt-0.5.2 tk-8.4.15 xorg-7.2 (lite) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take 2
On 8/18/07, Luca Tettamanti [EMAIL PROTECTED] wrote: Hello, in reply to this mail I will send a serie of 4 patches that cleans up and expands the alarm timer handling in QEMU. Patches have been rebased on QEMU CVS. Patch 1 is mostly a cleanup of the existing code; instead of having multiple #ifdefs to handle different timers scattered all over the code I've created a modular infrastructure where each timer type is self-contained and generic code is more readable. The resulting code is functionally equivalent to the old one. Patch 2 implements the -clock command line option proposed by Daniel Berrange and Avi Kivity. By default QEMU tries RTC and then falls back to unix timer; user can override the order of the timer through this options. Syntax is pretty simple: -clock timer1,timer2,etc. (QEMU will pick the first one that works). Patch 3 adds support for HPET under Linux (which is basically my old patch). As suggested HPET takes precedence over other timers, but of course this can be overridden. Patch 4 introduces dynticks timer source; patch is mostly based on the work Dan Kenigsberg. dynticks is now the default alarm timer. Luca -- there's a typo line 1432 on vl.c after applying all 4 patches (missing ';') C:/msys/1.0/home/Xian/qemu/vl.c: In function `win32_start_timer': C:/msys/1.0/home/Xian/qemu/vl.c:1432: error: syntax error before '}' token make[1]: *** [vl.o] Error 1 beyond this small typo, I managed to include this in a win32 qemu build. is there a specific practical test to see the improvement in a linux guest when running on a windows host ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] merging kqemu into mainline kernel?
On 8/16/07, Paul Brook [EMAIL PROTECTED] wrote: Yes, I mean the API. However in practice you'd probably want to try and share the implementation as well. In short it's likely to need rewriting before it's acceptable upstream. Paul P.S. Please don't top-post. Consider this your final warning. blame it on gmail. this is the default behaviour. it's obviously not intended... -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 8/13/07, Laurent Vivier [EMAIL PROTECTED] wrote: I know we are not in democracy, but if I can vote I'd like to vote to the idea of Christian Brunschen... We can modify qemu to test if the argument is a directory, if yes, it reads args from file args in this directory and for security the disk image must be in the same directory. I'd like to also vote for this solution, as I believe it's portable for windows hosts and generic enough to satisfy most needs. Christian
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 8/13/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing parser. No need for duplicated logic.) except it does not work yet on Windows! I tried with a 1 line file (all arguments on 1 line) and another file with each pair of arguments per line. qemu.exe @detaolb.cfg qemu: could not open hard disk image '@detaolb.cfg' type detaolb.cfg -L bios -m 128 -cdrom detaolb_v04.iso -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] Linux KDE vs. Windows
allocate more ram to your qemu guest it's the -m switch. Default is 128M, way too low for KDE. Try first 192, 256, and then 512 if you can afford it. On 7/24/07, Clemens Kolbitsch [EMAIL PROTECTED] wrote: hi! i've got a questions... just out of curiosity: when emulating windows xp, i get quite good speeds. however, when running linux, i can only work with it when turning off kde... it is WAY too slow. is there a known reason for that / does anyone know what i could be doing wrong? i'm emulating i386 (what else when using windows *g*) on a i386 using kqemu, newest version of qemu... just in case someone knows :-) greets, Clemens -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Blue Swirl [EMAIL PROTECTED] wrote: It's entirely possibly that qemu and real sparc hardware are behaving differently, but I'm not seeing this bus error under qemu. (I haven't got real sparc hardware, so I can only debug against qemu...) Right. Debugging the problem I found out that in Qemu, 64-bit loads and stores to unaligned addresses do not trigger any traps as they should. I'll commit a fix soon. The problem is in uClibc ldso, there is this kind of store. Running the program on qemu-sparc reveals another problem, probably because of these definitions in ldso/ldso/sparc/dl-sysdep.h: /* 4096 bytes alignment */ /* ...but 8192 is required for mmap() on sparc64 kernel */ #define PAGE_ALIGN 0xe000 #define ADDR_ALIGN 0x1fff #define OFFS_ALIGN 0x7fffe000 On Sparc32 the correct page alignment is still 4096. Because of these definitions, some code apparently tries to clear a 8k page, but only 4k of memory is mapped. I just managed a compilation of bash-3.2 using ncurses-5.6 and uClibc-0.9.29 inside a qemu-system-sparc (native compilation, no cross compilation). ldd ./bash points naturally to libdl.so.0, libc.so.0, ld-uClibc.so.0 ./bash Segmentation fault I do not have gdb compiled yet... I'll check soon with busybox ash, since I recompiled uClibc with the sched_affinity patch. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Christian MICHON [EMAIL PROTECTED] wrote: I just managed a compilation of bash-3.2 using ncurses-5.6 and uClibc-0.9.29 inside a qemu-system-sparc (native compilation, no cross compilation). ldd ./bash points naturally to libdl.so.0, libc.so.0, ld-uClibc.so.0 ./bash Segmentation fault I do not have gdb compiled yet... I'll check soon with busybox ash, since I recompiled uClibc with the sched_affinity patch. busybox-1.6.0 does segfault here too. I had to remove taskset as apparently the sched_affinity patch did not fix the linking step. is there a repository of sparc/uclibc patches somewhere ? Blue mentionned he'll have a fix for uclibc ldso. I'll try it using this dev environment as soon as it'll be out. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Rob Landley [EMAIL PROTECTED] wrote: When you get that kind of segmentation fault, see if hello world segfaults too. (In general, when building with a new toolchain, new C library, new kernel, new root filesystem packaging method, or a new system in general, if anything goes wrong back up a few steps and make sure hello world works before trying to debug anything fancier.) I was not clear then. I've binutils already compiled versus uClibc for sparc, and it works. Some of those binaries from binutils are bigger than the expected size of final uclibc dynamic busybox. of course, as soon as I got uclibc compiled, hello world comes first to my mind, and it was working. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Rob Landley [EMAIL PROTECTED] wrote: I look forward to a fix. It would be nice to add sparc to the actually works list. :) that's 2 persons looking forward to it. ;-) today's results: - uclibc ok (minus the segfaults coming from it) - conf from busybox segfaults - bash segfaults - busybox segfaults - gcc does not build without bash (I'll replace with ash tomorrow) - binutils ok - ncurses ok (I need to look at uclibc' conf now) - make ok - bzip2 ok - coreutils ok - findutils ok Blue swirl, please note that the porting of DetaolB to sparc32 will take more time than scheduled, once the segfault issues are covered. I'd like to spend some time testing firmware and cross compilation :) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/10/07, Bernhard Fischer [EMAIL PROTECTED] wrote:
On Wed, Jul 04, 2007 at 09:54:48PM +0200, Cedric Hombourger wrote:
The busybox link failure has an existing entry in mantis:
http://www.uclibc.org/bugs/bug_view_advanced_page.php?bug_id=1356
Just to expand on this one last time, here is the help-text of taskset:
config TASKSET
bool taskset
default n
help
Retrieve or set a processes's CPU affinity.
This requires sched_{g,s}etaffinity support in your libc.
This was slightly adjusted in uClibc trunk (to stub it out if the syscall is
unavailable),
a patch against 0.9.29 which updates this can be found here:
http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/toolchain/uClibc/
HTH,
I hit this today. I'll need this patch then, since I did not see the problem
on i686. Thanks!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] Hardware Detection in Qemu
On 7/8/07, Michael Fisher [EMAIL PROTECTED] wrote: I have run various live Linux CD distributions (Knoppix, DSL, Ubuntu, etc.) under QEMU and was wondering if there is really a need to run the various hardware detection scripts in the live CDs? Obviously, a script for getting an IP address is needed but if I know I am running the distro under QEMU, do I need to check for USB, SCSI, AGP, PCI and the other detection scripts? in short: no, you don't need so much hardware detection. If QEMU is already doing that, can't I just tweak the live distro to match QEMU and then let QEMU do the work when it is placed on various host computers? if you're targetting a specific version of qemu, on which hardware's list is specified/frozen, then yes, it's best to custom each of your linux guest to speed up the boot sequence. I see 3 ways: 1) by command line: you can add parameters like noacpi, tweak the ide probes, etc... slax and dsl give you quite a good list to start with... 2) by customizing the /etc/init.d/* scripts, and re-authorizing the iso If you do this, you've to keep in mind the new iso is for your guests only... 3) use DetaolB. It's one of the many reasons why I created it. :) Seriously, you create your own distro. The trick is in getting the init scripts to as little as possible, and putting all needed hardware modules *only* in your vmlinux, thus removing modprobing, which actually takes quite a lot of time when inside qemu. Currently, most of my testing is done using Win XP as the host but in the future I will be looking at Linux and Macs as hosts also. I'm in the same situation. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] Hardware Detection in Qemu
On 7/9/07, Michael Fisher [EMAIL PROTECTED] wrote: Thanks...I am working with a couple of distros I want to modify so they will boot faster on QEMU and also utilize persistence. Customizing the /etc/init.d/* scripts will be my next step. with minor modifications (1 file) you can get similar persistence in detaolb... I guess I'll need to add some switches on the cmd line to enable it without having to feedle with the initramfs.cpio.gz -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] Hardware Detection in Qemu
On 7/9/07, wangji [EMAIL PROTECTED] wrote: Christian Mignon wrote : 3) use DetaolB. It's one of the many reasons why I created it. :) But slax as dsl do have X ,when DetaolB will include X with uclibc not just busybox upgrade to version 0.4. X is already in since last version. :) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
[Qemu-devel] problems booting a sparc32 kernel
Hi list, I used the .config I was given (originally for 2.6.11+tcx), and did minor tweaks to upgrade it to 2.6.21. Once compiled, the kernel vmlinux does not boot. I've error messages like: unknown filesystem type Not a bootable ELF image unknown filesystem type Not a Linux kernel image unknown filesystem type Not a bootable a.out image etc... it complains about elf and a.out format I believe I used a correct .config file. Most drivers and devices are in repect with the original 2.6.11 config file. One big difference though: my vmlinux is ~4Mb, when the original vmlinux-2.6.11+tcx was 11Mb. How was this file processed (if the owner recognizes his work) ??? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
[Qemu-devel] Re: problems booting a sparc32 kernel
ach! posted too fast! I had to use image instead of vmlinux. I can see a boot sequence working now... not far now... On 7/6/07, Christian MICHON [EMAIL PROTECTED] wrote: Hi list, I used the .config I was given (originally for 2.6.11+tcx), and did minor tweaks to upgrade it to 2.6.21. Once compiled, the kernel vmlinux does not boot. I've error messages like: unknown filesystem type Not a bootable ELF image unknown filesystem type Not a Linux kernel image unknown filesystem type Not a bootable a.out image etc... it complains about elf and a.out format I believe I used a correct .config file. Most drivers and devices are in repect with the original 2.6.11 config file. One big difference though: my vmlinux is ~4Mb, when the original vmlinux-2.6.11+tcx was 11Mb. How was this file processed (if the owner recognizes his work) ??? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
ok, I found this file (google for it): stage3-sparc-2006.0.tar.bz2 I put it into a vmdk image file, preformatted in ext2 fs. I touched up a few files and used the sparc kernel and binaries from the qemu-windows page. I've now a native compiler for sparc32. I managed some stuff with it already. If the kernel patches I've works with this compiler, porting DetaolB to sparc32 should be fine. I'll just take some times (native compilation in qemu). Many of you will say: why not cross-compiling ? It's hard to setup. Actually, the paper from Rob at OLS should help me a lot when he'll release it. ;-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/5/07, Rob Landley [EMAIL PROTECTED] wrote: What's the difference between deltaolb and Firmware Linux, anyway? I'm still curious about this. a few differences, quite minor actually (that's why I said in the past we shared many common goals :-) )... I actually started this in 2002, but then hit many bugs in uclibc. In the end, I actually used a trimmed LFS approach, using zisofs. My bootable env then was ~45Mb. At that time, buildroot was also starting... I lacked of time to work on it. The biggest difference today is that your firmware is based on automation or Makefiles, whereas I still use a LFS type of approach. I first build a static minimal toolchain with a static busybox: all native, no cross compilation. Then I chroot in it, compile uclibc, busybox, the toolchain. The rest is obvious, but quite manual. I really should do Makefiles... The other difference is that I base detaolb on aufs/squashfs (I do not think you passed that stage yet, if I recall not all the archs you're targetting can take this). That's today's improvement over the stuff I did in 2002 using zifofs. Oh, by the way, the Fedora for Arm project is also building natively on arm, but they got some fast ARM hardware and stuck lots of DRAM and hard drive space onto it rather than using QEMU. in 2003/2004, I also worked on porting linux to an Ipaq h2215. I actually then used buildroot arm precompiled, and managed to chroot in it using nfs over usb. quite cool, and the speed was better than qemu today. It was just a 400Mhz Xscale. I'm still interested in your cross compiling tutorial. I believe we all are :) If I start putting too many archs in the picture, I believe DetaolB will be redundant with Firmware. This is not intended. Originally I wanted to share the portable x86 env I carry on my usb key. Some of you asked for a sparc32 port. I'll complete this one at least (I'm progressing quite fast on it). -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 6/30/07, Blue Swirl [EMAIL PROTECTED] wrote: As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs? ok, I documented myself, and I'll try on sparc32. any hint on patches, config files for the kernel ? will uclibc work well enough on sparc32 ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/4/07, Cedric Hombourger [EMAIL PROTECTED] wrote: You may want to look at crosskit.sourceforge.net thanks for this hint. I haven't looked at detaoib yet but it was surely created before crosskit and may therefore be a safer bet. DetaolB aims to be a native solution, not a cross compiling tool. I've to get to the point where a native sparc32 toolchain will be usable in detaolb-sparc32... -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/4/07, Blue Swirl [EMAIL PROTECTED] wrote: Aurora is fine, Debian should work on Sparc too. when trying to boot aurora, it stops and complains about /dev/sda I already gave a hda disk. is it a problem of size or a problem of command line switch ? what command line did you use when you reported a successful installation of aurora earlier this year ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/4/07, Andreas Färber [EMAIL PROTECTED] wrote: Is there a special reason to use Aurora? I thought it was an abandoned port of Fedora Core 2... (with Fedora 7 available nowadays) Debian was the only maintained Sparc distribution I could recently find for qemu. that's the only port I found. maybe I did not look enough. thanks for the hint. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/4/07, Blue Swirl [EMAIL PROTECTED] wrote: what command line did you use when you reported a successful installation of aurora earlier this year ? qemu-system-sparc -boot d -hda aurora-1.0.img -cdrom aurora-1.0-sparc-disc1.iso I tested Aurora 1.0 and 2.0, 2.1 can't read from cdrom. I tried 2.98 only briefly and never 2.99. I did this too. maybe aurora is not a good idea then. maybe simply a stage3 sparc from gentoo would do ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 6/30/07, Thiemo Seufer [EMAIL PROTECTED] wrote: The reason why distributions drop sparc32 is the unmaintained kernel. Nobody stepped up for Linux kernel maintenance in the last years. Debian managed to keep up a sort-of working kernel for the last release, the people who put their time into it are disinclined to repeat this exercise. good point. I'm not a kernel maintainer, I'm just a distro maker. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 6/30/07, Johannes Schindelin [EMAIL PROTECTED] wrote: Hi, On Sat, 30 Jun 2007, Blue Swirl wrote: On 6/30/07, Christian MICHON [EMAIL PROTECTED] wrote: DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. As the number of Sparc32 distributions keeps approaching zero, could you consider porting DetaolB to non-x86 CPUs? Yes, please! Ciao, Dscho there might be a arm port (I'll need to figure out the framebuffer part though). the original target of detaolb is to have a quick x86 development environment that can boot/run quickly in qemu. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
[Qemu-devel] ANN: DetaolB v0.4 is released
DetaolB aimed to be a much-less-than-a-floppy x86 linux live distro. Now, it's evolving more into a-la-slax type of distro. DetaolB v0.4 has been released 29th,June 2007 on sf.net = http://sourceforge.net/project/showfiles.php?group_id=140321package_id=155481release_id=519786 Mailing list: [EMAIL PROTECTED] Changelog: == - updated aufs and squashfs - increased the list of modules - vesafb-tng included (default boot is 800x600x24bpp) - included some X11 functionality: log in as root, then xinit - included ext2fs utilities: you can now work in qemu/vmplayer - self sufficient to compile itself and linux-2.6.21 - killing features: git, vim Detailed list of modules: = barebone: busybox-1.6.0 e2fsprogs-1.39 uclibc-0.9.29 zlib-1.2.3 dev: bash-3.2 binutils-2.16.1 bison-2.1 bzip2-1.0.4 coreutils-6.9 (od tail) cpio-2.8 diffutils-2.8.1 findutils-4.2.31 flex-2.5.33 gawk-3.1.5 gcc-3.4.6 git-1.5.2 gzip-1.3.12 headers-2.6.21 less-382 m4-1.4 make-3.81 ncurses-5.6 patch-2.5.4 tar-1.17 vim: vim-7.1 x11: fvwm-2.4.11 xfree86-4.2.0 -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] Emulation: Building solid files
you could pack the binaries and the image into a 7-zip sfx (but that is for windows hosts only). just google for it and you'll get the procedure. I've done it a few times already. what is your host ? linux or windows ? On 6/27/07, NetAudi [EMAIL PROTECTED] wrote: Hi beastcoders, My question is if you are thinking in improve Qemu to add singular characteristics whose aren't implemented in any VM sofware: I.E.: Building virtual machines taking only one big binary file (merging Qemu engine and HD image file). It could be good for future portable aplications. I thought this because I'm triying to do the simplest-ultra-secure Internet navigatior. The idea is to generate a VM (with the lightest/functional O.S. posibility and increase speed at top) to content a Firefox installation (with the most used complements into it). The main is to load all this VM into the RAM and when it will turn off, it never has to save the session changes, it allways must start at the beginning point. Sorry, allways not. Sessions only will be modified in security-updates and/or Firefox-complements. Troyans, virus, spyware... will be better managed by people who hasn't any idea in computers, because I wan't to transmit the simplest concept: If you want to use the Internet to do critical operations and you are very scared by hackers, virus... because you hasn't any idea of manage security in computers, you only have to run another VM-Firefox to enter in I.E: bank sites and don't worry because you are keeped by the security of a castle I only want if you will implement that kind of emulation. REGARDS -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
[Qemu-devel] Re: ANN: DetaolB v0.3 is released
On 6/16/07, Rob Landley [EMAIL PROTECTED] wrote: On Thursday 14 June 2007 17:13:32 Christian MICHON wrote: * /proc/miniconfig.gz: main ideas from Rob Landley, need documentation Actually, there was documentation for this before there was code. You can follow my development of the concept: (...) I'm sorry Rob, I meant I need to document the changes I brought to your original idea. Download the iso, and once it's finished booting inside qemu, log in as root and do this: vi /proc/miniconfig.gz you'll understand what I meant by not having documented (my changes)... + gcc-3.4.6 Heh. You're building qemu with your toolchain, aren't you? :) nope, not yet. the reason for this gcc version is also due to colinux requirements (I need a vmlinux api compatible with gcc-3.4.6) I actually intend to deliver a few toolchains soon. But qemu is definitely going in as a loadable module soon after Xwindows will be in. :) One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. excellent... -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
[Qemu-devel] DetaolB: a small linux distro developed for qemu
Hi qemu list, this is a small donation for a x86/32bits small distro I'm toying with. it's reached a small 1st step (bootable and stable enough): v0.1 lots of kudos and credits to: - linux developers - qemu developers - busybox developers - and soon uclibc developers - of course, Rob Landley who's in direct cc of this (look Ma!: signature...) my target was to have a small bootable iso, even if I do not use kqemu. sorry, I do not intend yet to support other architectures. I'll try to keep it small, but feature suggestions are welcome, until detaolb becomes bloated... http://zitu.hostarea.org -- Christian -- There's a symlink from awk to gawk, if you're using gawk! If you're not using gawk, there's no symlink from gawk to awk! Use the standard names, _please_! - Rob Landley
[Qemu-devel] detaolb is now in sourceforge.net
actually, it's been registered by myself in 2005 ;) Detaolb aims to be a much-less-than-a-floppy linux distro. It's been thought and built in/for qemu all along. Only recently I started using colinux to speed up some dev ( cofs in colinux is a killer feature over samba inside qemu, btw... ). the correct home for this small distro should be from now on: http://detaolb.sf.net you can discard the previous location (too pointy on including ads). it'll stay as the original release and will not be updated. the sf.net page will be updated, and is properly connected to my email. it was really painful to set up the web interface of sf.net... -- Christian
Re: [Qemu-devel] why -hda myimgfile can not work ??
On 5/4/07, tang peilei [EMAIL PROTECTED] wrote: I first create a img file using command qemu-img create myimgfile 10M then I use this img file in my qemu . (qemu -kernel ... -initrd ... -hda myimgfile). but when i am in linux shell , I can not find any hda info even in dmesg, and I can not fdisk or mount hda. who knows what is the problem ??? the problem might be in your guest linux kernel (no ATAPI/IDE modules or built-in). Could you send your kernel .config, and inform us on the revision of qemu you're using and the guest's arch you're using (x86, x86-64, arm...) ? That'd be a start... -- Christian
Re: [Qemu-devel] why -hda myimgfile can not work ??
On 5/4/07, tang peilei [EMAIL PROTECTED] wrote: the target arch is arm. and I was just use the download qemu arm-test kernel and initrd file to run. It has a config.gz in /proc, but I can not copy it out, becase the net can not work in my qemu, and the hda can not use .Is there any other way to copy data from qemu system to my phy system ? are you using http://fabrice.bellard.free.fr/qemu/arm-test-0.2.tar.gz ? what is the exact cmd line you use ? -- Christian
Re: [Qemu-devel] qemu bootstarp error!! unable to compile!
On 5/4/07, gaurav gunjan jha [EMAIL PROTECTED] wrote: Hello Friends !! I am trying to install Qemu from source on suse 10 suse 10 implies gcc = 4.0.x, so you cannot compile a working qemu. another alternative than installing gcc3 from sources is to install Suse 9 packages... configure --prefix=where_you_want --enable-languages=c --with-gnu-as --with-gnu-ld --with-included-gettext --disable-nls make bootstrap install might be useful to restrict your gcc target to x86-32bits -- Christian
Re: [Qemu-devel] [PATCH] ARM XScale core features and PXA270 and PXA255 emulation.
On 3/16/07, andrzej zaborowski [EMAIL PROTECTED] wrote: Implements basic differences between XScale and plain ARM. The patch also adds the main on-chip peripherals of PXA2xx: interrupt controller, DMA, GPIO controller, SSP, I2C, I2S busses, UARTs, FIR port, RTC, Clock/Power/Memory managers. Cheers, Andrew interesting (I haven't tested it yet)... how to use this patch ? beside the -portrait extra switch, applying this patch would make arm-softmmu a pxa2xx by default ? if so, it's very interesting: I've an ipaq (H2210) and I was taking part of a port of linux on it. One big drawback then is that I burned a few SD cards to get a kernel working, but this patch could be a good fix to my problems... Do I just need the 2 emails with pxa2xx patches ? or is there more needed ? Last, but not least: do you think we could emulate a windows CE pocketpc in this way ? -- Christian
Re: [Qemu-devel] Hello Friends !! need some help !!
On 4/11/07, gaurav gunjan jha [EMAIL PROTECTED] wrote: (...) qemu-img create -f qcow linux2.img 100M Formating 'linux2.img', fmt=qcow, size=102400 kB but when i invoke the command qemu linux3.img then i get the a new terminal window and the following display on it the Fatal error .boot from hard dik failed what option i need to set to boot from hard disk? it's not going to work if you just created linux2.img and you intend to boot linux3.img by the way. :) quite likely, here's the flow you need: 1) qemu-img create -f qcow linux2.img 100M 2) qemu -L path_to_qemu_bios -hda linux2.img -cdrom an_iso_that_can_install_an_os -boot d 3) once the os is installed: qemu -L path_to_qemu_bios -hda linux2.img I disagree with the statement: documentation on internet is not good enough. You obviously missed this very good link: http://kidsquid.com/cgi-bin/moin.cgi/QuickStartGuide -- Christian
Re: [Qemu-devel] Bugs
On 3/31/07, James Jacobs [EMAIL PROTECTED] wrote: Using the start.bat file included with the QEMU package (except changing cd-rom and hard disk image filenames as appropriate). I haven't adjusted any audio settings, I'm using whatever the defaults are. which package ? you mentionned a package. not me. did you download the zip containing win32 executables ? I find strange even knoppix does not work with raw images. Have you tried fdisk inside the guest ? and what dmesg | grep hda gives you ? It doesn't even get that far. I get this kind of error: qemu: could not open hard disk image 'c:\e2\linux\debian.img' and QEMU then quits. FILEMON is showing that the file is being opened read-only for some reason, and the resultcode is shown as SHARING. I'll be offline for a week: send the start.bat to the list, hopefully someone will look into it. -- Christian
Re: [Qemu-devel] Bugs found
On 3/30/07, James Jacobs [EMAIL PROTECTED] wrote: 3 more bugs that need attention... a) serious: Image files, even those created by the version of qemu-img.exe that comes with QEMU 0.90, are unreadable by QEMU 0.90, QEMU 0.82 works fine with them. b) less serious: Out of environment space error when starting. c) serious: audio: Failed to create voice 'es1370.adc error when starting. 3 more bugs that need attention... some info missing here... host type, guest type, command lines, and most important type of images you're creating. from your email, you're using released versions, not cvs snapshot, right ? personally: I do not see (a) on windows host, I do not know which guest gives you (b) and I do not use audio, so I cannot confirm (c)... -- Christian
Re: [Qemu-devel] Re: 3 bugs found
On 3/30/07, James Jacobs [EMAIL PROTECTED] wrote: Host type is Win98SE. Guest types are Debian Linux 3.1 and Knoppix. Not specifying a type of image to qemu-img (using default, whichever filesystem that is - it doesn't say). no experience whatsoever on win98se host. I usually use it as guest. :) Using the start.bat file included with the QEMU package (except changing cd-rom and hard disk image filenames as appropriate). I haven't adjusted any audio settings, I'm using whatever the defaults are. which package ? from your email, you're using released versions, not cvs snapshot, right ? Yes. not many solutions here. Could be 32 bits related issues, because in my case I usually use it in XP host, and I do compile my own binaries... I find strange even knoppix does not work with raw images. Have you tried fdisk inside the guest ? and what dmesg | grep hda gives you ? -- Christian
Re: [Qemu-devel] Moving pre-installed Windows to qemu?
quite impossible: the hardware inside qemu guest would be different with the real hardware of the laptop. worst case: error 7b and blue screen. it will not go further, and it means you need to reinstall everything. best case: it moves further in safe mode, but then you'll need the xp cdrom for installing updated drivers. I've seen this working with win95. I had a complete dd of an old win95 harddisk, and was able to boot my old pc when I actually threw away the hardware... :) On 3/19/07, Stefan Monnier [EMAIL PROTECTED] wrote: [ The Wiki seems to be down [Errno 28] No space left on device. ] As soon as I received my new laptop I began by shrinking its XP partition and installing Debian on it. Now, I don't intend to use XP on it ever, but my wife would need to do that occasionally. I'd rather be able to do it without stopping Debian by running XP under QEMU by am wondering how I could do that using only my current partition (or the rescue partition): Lenovo did not provide an actual DVD or some such install media. Any idea? Stefan PS: I could consider using Xen as well if that makes it easier, although I'd much rather use qemu since it doesn't require any special kernel. -- Christian
Re: [Qemu-devel] QEMU + -std-vga + XFree86
On 3/26/07, Kyle Hubert [EMAIL PROTECTED] wrote: It does work in cirrus mode for 1024x768. I was under the impression that it was all the cirrus driver would support. However, the std-vga mode supports vga 799 and 798 in the console. (1600x1200:24bpp and 1600x1200:16bpp respectively) The X driver seem forever confused saying there is no available video memory. Thanks a lot for the help. no obvious problem in the xf86config file. when all fails, use the framebuffer :) and Xfbdev (fbdev driver instead of vesa) you might need a patch called vesafb-tng to reach such size. I haven't tried successfully though. Appending the proper parameters -append video=vesafb:[EMAIL PROTECTED], I basically reach at most 1280x1024. -- Christian
Re: [Qemu-devel] qemu keyboard problem
1) go into the monitor of qemu (ctrl-alt-2) 2) key in: sendkey ctrl-alt-f1 3) go back to the emulated screen (ctrl-alt-1) it should have swapped back to text mode. sorry for the late reply, but your email just made it now to the mailing list. On 3/14/07, Halim Sahin [EMAIL PROTECTED] wrote: Hello, Yesterday I installed debian etch in a qemu virtual machine. How can I switch from an virtualized x-server under qemu to the virtualized text-console? If I type ctrl+alt+f1 the system switches to console 1 of the host. I need the console of the guest linux system. Thanks Halim -- Christian
Re: [Qemu-devel] missing Pause/Break key in QEMU / Ubuntu host, XP guest, please help!
you could use sendkey in the monitor console of qemu. This is the only way on xp host to send a ctrl-alt-delete to a xp guest to login... On 2/10/07, Georg Schlomka [EMAIL PROTECTED] wrote: Hi! We use Qemu un an Ubuntu host and want to run XP guests. No problems there. But the most important XP Application we run *absolutely needs* the break/pause key, especially the combination ctrlpause. Unfortunately, it appears that this does not work. After looking through some of the source (monitor.c and keymaps/common), it appears that the pause key was simply omitted. Can anyone tell us how to fix this problem? We are not familiar with the internals of qemu at all, but we would manage a recompile with altered sources... If we cannot get the pause key to work, we propably have to abandon our project to switch all our machines to Ubuntu and stay with XP :( Thank you for your help George -- Christian
Re: [Qemu-devel] QEMU + -std-vga + XFree86
On 3/26/07, Kyle Hubert [EMAIL PROTECTED] wrote: I tried using the newer video appendage and it didn't seem to work. I had to use the older vga=. I believe you are talking about the kernel boot param, yes? yes. normally the vesafb-tng is supposed to address missing functions or resolutions of the current vesa present in the kernel. The cool feature is to be able to swap resolutions without rebooting, plus being able to get higher refresh rates than 60hz. How about this for more information. The XFree86 VBE extension does the following code: (...) for the rest of your email, that part is too obscure to me (I never went inside the bios itself: I'm doing more OS assembly and kernel compiling than doing active development of qemu). good luck! -- Christian
Re: [Qemu-devel] QEMU + -std-vga + XFree86
On 3/26/07, Kyle Hubert [EMAIL PROTECTED] wrote: Hi, I'm working with QEMU on an XFree86 machine. I was desirous of having 1600x1200 working in the virtual machine, so I looked at using the -std-vga option with the vesa X driver. While initializing X, I get the following: (...) could you send your xf86config file ? does it work in cirrus mode ? -- Christian
Re: [Qemu-devel] qemu-cvs-2007-3-22 compile error (in cygwin)
use mingw to compile qemu for windows hosts, not cygwin. if I recall well, SDL does not cope well on cygwin. -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
is it on a freshly created qemu image, or one created with qemu = 0.8.2 ? what is the format of the qemu image ? raw, qcow, qcow2 ? right now (and I'm on windows hosts), latest qemu and 0.9.0 work well. Most of the pb I see with kernel-kqemu are time out on hdc (cdrom) if I boot on hda with linux guests. what happens if you use a slax bootable iso, booting on it and accessing your data on hda ? this works for me and is very stable now since qemu 0.8.2. On 3/15/07, Halim Sahin [EMAIL PROTECTED] wrote: On Do, Mär 15, 2007 at 11:12:41 +0400, Brad Campbell wrote: Halim Sahin wrote: Hello list, I experienced several problems with qemu under linux using kernel 2.6.18. The guest system is a debian testing, the host a debian unstable. kqemu is the newest version from www.qemu.org. The guest can not start if I give -kernel-kqemu. The last message is kernel panic. Another problem is the performance of the guest harddisk. There is no ide dma aktivated and hdparm fails to aktivate it. If I try to shutdown the guest, I am only getting system halted but the qemu did not shutdown. What version of qemu are you using ? I am using qemu 0.9.0 but this problem happends with 0.8.2 too. Halim ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic
On 3/15/07, Halim Sahin [EMAIL PROTECTED] wrote: Hello, On Thu, Mar 15, 2007 at 09:14:46AM +0100, Christian MICHON wrote: is it on a freshly created qemu image, or one created with qemu = 0.8.2 ? 0.8.2 was used to create the image what is the format of the qemu image ? raw, qcow, qcow2 ? Raw I wanted to discard any change of behaviour between formats and releases of qemu-img. You could have had a compressed encrypted qcow(2) for example... right now (and I'm on windows hosts), latest qemu and 0.9.0 work well. Most of the pb I see with kernel-kqemu are time out on hdc (cdrom) if I boot on hda with linux guests. what happens if you use a slax bootable iso, booting on it and accessing your data on hda ? this works for me and is very stable now since qemu 0.8.2. Hmm I tested it now on my other host system. There is a kernel 2.6.15 running under debian sarge. All works fine. the described errors are not visible. There runs a qemu 0.8.2 too but the kqemu module is an older version. Perhaps the kqemu module causes these problems?? Thanks Halim I'm using the latest kqemu each time, and it works... -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu Changelog VERSION
On 2/5/07, Fabrice Bellard [EMAIL PROTECTED] wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/02/05 20:46:55 Modified files: . : Changelog VERSION this is starting to feel like christmas :) woot! -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to run qemu (i386) without hda image?
On 1/28/07, Neo Jia [EMAIL PROTECTED] wrote: hi, I notice that this would be a very newbie question. Hope you can point me out. I am going to simulate i386 arch. But I cannot run it just with initrd and vmlinuz just like running it for mips arch. It always complained about missing the hda image file. When I applied the hda.img file, the kernel will panic due to the file format (eg, ext3). Acturallly, my goal is trying to use qemu to setup a kernel debugging envir. Your help will be greatly appreciated! Thanks, Neo is your problem fixed by the way ? -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] current qemu cvs broken for mingw hosts
On 1/30/07, Paul Brook [EMAIL PROTECTED] wrote: Did you test it? I'm fairly certain it still won't work. AFAICS You're not setting the field anywhere. it solved the compilation, which was broken, which was my primary concern. Your patches normally don't break the build :) so in a sense, with regards to the current cvs state, it helps fixing the compilation, without segfault for example. the binary works. The struct statement was missing the chr. Now, in term of functionality, I do not know how you test it, if this was your question. -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to run qemu (i386) without hda image?
remove root=/dev/hda. you may have not compiled block drivers as built-in, and fc3.img may not have the proper init files (which should be inside your initrd). On 1/28/07, Neo Jia [EMAIL PROTECTED] wrote: The following is the command line i used qemu -kernel vmlinuz-2.6.20-rc6 -initrd initrd-2.6.20-rc6.img -hda fc3.img -nographic -append console=ttyS0 root=/dev/hda The following is the error message ... (...) Switching to new root switchroot: mount failed: 22 umount /initrd/dev failed: 2 Kernel panic - not syncing: Attempted to kill init! On 1/28/07, Christian MICHON [EMAIL PROTECTED] wrote: one possibility is to include your kernel and initrd inside a bootable iso (mkisofs and isolinux are your friends: look at the man pages for numerous solutions). the kernel panic could be actually missing block drivers or your root parameter is wrong. On 1/28/07, Neo Jia [EMAIL PROTECTED] wrote: hi, I notice that this would be a very newbie question. Hope you can point me out. I am going to simulate i386 arch. But I cannot run it just with initrd and vmlinuz just like running it for mips arch. It always complained about missing the hda image file. When I applied the hda.img file, the kernel will panic due to the file format (eg, ext3). Acturallly, my goal is trying to use qemu to setup a kernel debugging envir. Your help will be greatly appreciated! Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian -- There's a symlink from awk to gawk, if you're using gawk! If you're not using gawk, there's no symlink from gawk to awk! Use the standard names, _please_! - Rob Landley ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source
based on *quick* benchs and without entering too much in detail (in case I'd violate EULA), it seems faster than qemu+kqemu on windows hosts :( -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source
sorry I meant :) it's a stupid typo mistake... basically: video is faster, hdd access is faster. I'll see if I can gather more figures. I hope too we can put these improvements back inside qemu of course! :) On 1/16/07, Paul Brook [EMAIL PROTECTED] wrote: On Tuesday 16 January 2007 08:25, Christian MICHON wrote: based on *quick* benchs and without entering too much in detail (in case I'd violate EULA), it seems faster than qemu+kqemu on windows hosts :( Why is that a bad thing? VirtualBox is GPL, kqemu is not, so I'd say VirtualBox being faster is a good thing. It means there's no need for proprietary kernel modules. Paul -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] has anyone started working on a nios2 target ?
I've been googling around and checking the mailing list archives, and I cannot find the answer. Has anyone started a porting of such target ? (this is not a feature request) -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] USB EHCI development nearing completion
I tested it on win32 host. Apparently a typo mistake (see updated patch) how to use it ? diff -Nur ehci.patch ehci-xian.patch --- ehci.patch Thu Jan 4 09:50:17 2007 +++ ehci-xian.patch Thu Jan 4 10:40:26 2007 @@ -1722,7 +1722,7 @@ +printf (buffer is %p (+%d)\n, s-buffer, (uint8_t*)s-buffer - (uint8_t*)s); + +pci_conf = s-dev.config; -+pci_conf[0x00] = 0x86 ++pci_conf[0x00] = 0x86; +pci_conf[0x01] = 0x80; // Intel VID +pci_conf[0x02] = 0x55; +pci_conf[0x03] = 0x55; // Made up product ID On 1/4/07, Mark B [EMAIL PROTECTED] wrote: Paul, I don't see anything to do with EHCI in Chromium. I was just referring to the 3D patch as an example - maybe this is causing confusion. Did anyone else get a chance to look at the EHCI emulation patch? Thanks, Mark -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu speed vs vmplayer?
On 12/15/06, Paul Brook [EMAIL PROTECTED] wrote: I've got a copy of today's CVS, You missed my point entirely. kqemu is a closed source module, there's absolutely nothing we can do with it. well, we can use kqemu at least, right? :) interesting benchmark: I started removing most of the graphics code (which I originally believed was slowing down qemu a lot) and started running through ssh on windows host + tap-win32 patch. Using kqemu, I see no improvement in calculations, meaning the graphical part (sdl) is not the main blocking point. Next on my list of trials is the disk/io (we did some pthread experiment in the past, I think we can get some more bandwith here). one last point: last time I used qvm86 for windows host, it did not give good results. Hanged OS, several reboots, qemu hanging forever. And back then I was using up to date qvm86 cvs. Is qvm86 still active ? If yes (for windows host), I'll try to do newer benchmarks. -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu speed vs vmplayer?
On 12/15/06, Paul Brook [EMAIL PROTECTED] wrote: QEMU is an open source project (and this list is hosted on a site that is explicitly for open source projects)· Thus any solution that involves proprietary closed source modules is offtopic. ok, politically incorrect. point taken :) yet, what about the second part of my reply ? Is qvm86 still active ? if yes, great. if no, what do you need to restart it ? (else than dedicated developpers, of course). As far as I can see, no qvm86 check-in for 15 months now... -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: NBD server for QEMU images
On 12/12/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: How is everybody missing the point? :-) mount -o loop doesn't mount qcow images. you could also mount it through a samba tunnel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: question on samba/linux_guest
it was silly of me to discard the qemu-tap stuff actually... Unless I use tunneling, I cannot access the guest from the windows host directly using an IP address. And windows refuses to mount something like \\10.0.2.16:\ The problem disappears if I use tap-win32... So now I can do some linux specific stuff inside the guest (kernel compilation) and get the result out of the guest filesystem using samba (launch a parallel session of qemu on windows using the freshly compiled kernel) If someone one day finds a way to do it using slirp/user mode, I'm still interested... :) On 11/30/06, Christian MICHON [EMAIL PROTECTED] wrote: I would like to do the opposite: having a Windows host and a properly configured samba inside a linux guest, use windows explorer to browse specific disk areas of the linux guest. I can already do this using vmplayer in host-only network mode, similar to the network user mode over slirp. The problem is that I do not know what IP address I should use when mapping the disk inside windows host. Indeed, the IP address inside the qemu guest is something like 10.0.2.15, but I cannot access it from XP. I tried to fiddle with -redir options, but it refuses to redirect port 445 (though I'm admin on XP). Has anyone managed this yet ? If so, please share the command lines. It must be possible, but maybe not easy. Just a precision: I want to use the slirp mode only, not the tap-win32 stuff. Thanks in advance -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] question on samba/linux_guest
Hi list, I know for sure -smb option is meant for using samba inside a Windows guest inside a linux host. I would like to do the opposite: having a Windows host and a properly configured samba inside a linux guest, use windows explorer to browse specific disk areas of the linux guest. I can already do this using vmplayer in host-only network mode, similar to the network user mode over slirp. The problem is that I do not know what IP address I should use when mapping the disk inside windows host. Indeed, the IP address inside the qemu guest is something like 10.0.2.15, but I cannot access it from XP. I tried to fiddle with -redir options, but it refuses to redirect port 445 (though I'm admin on XP). Has anyone managed this yet ? If so, please share the command lines. It must be possible, but maybe not easy. Just a precision: I want to use the slirp mode only, not the tap-win32 stuff. Thanks in advance -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PS3 - XP
yes, but this one seems more interesting... http://video.google.com/videoplay?docid=-582288598817619782q=qemuhl=en Dscho on lime lights :) On 11/28/06, Laurent Desnogues [EMAIL PROTECTED] wrote: This looks real and funny :) http://www.ps3scene.com/news/static/WindowsXPonPS3viaQemuonLinux-1164389620.php Laurent ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Config file support
IMHO, I believe: - python inside monitor is uncalled for (average python installation size is big, no ?) - xml is still too big a format for something we can do by shell script (joke: why not yaml ?) -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Config file support
how about this ? (it's yaml, not xml) the idea would be to store all cfg in one file and switch at boot time which guest you want to boot... This is just a draft, and your mileage may vary. More readings at: http://yaml.org http://www-128.ibm.com/developerworks/library/x-matters23.html --- guests: - name: win30 kqemu: no ram: 16 boot: c fda: none hda: win30.img cdrom: none type: isapc net: none audio: none - name: rh72 kqemu: kernel ram: 128 type: pc fda: none hda: rh72.qcow cdrom: enigma-disc1.iso boot: c net: user,...,... - name: bartpe kqemu: user ram: 256 type: pc fda: none hda: none cdrom: pebuilder.iso boot: d net: none - name: xp_lite kqemu: kernel ram: 384 type: pc fda: none hda: nliteos.qcow cdrom: nliteos.iso boot: c net: user,...,... -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Config file support
On 10/24/06, Blue Swirl [EMAIL PROTECTED] wrote: I'd recommend Qemu Launcher (https://gna.org/projects/qemulaunch). If Qemu gets a config file and a configuration utility, it should be similar in my opinion. I thought the qemu config file could be having the noble aim to be multi-host. Using such gtk/gui interface would work on win32 hosts too ? -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] config file support
On 10/22/06, Rob Landley [EMAIL PROTECTED] wrote: As a random end-user, I really like being able to run qemu without a config file, configuring it entirely on the command line. I'd be highly disappointed if qemu turned into another Wine. Rob we've a lot to gain from it. Think twice: the shell and the host you use behaves in a certain way because of the way you write the command line. Migrate to a different OS for the host and you might be done for: I believe the config file support will help solving problems and debug, but most important will help promote qemu usage to the rest of the community (understand: non-developpers). Rob: you're far from being a random user, right ? :) -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] DSC timeouts using all of -hda -hdb -hdc -cdrom
On 8/19/06, J M Cerqueira Esteves [EMAIL PROTECTED] wrote: So the culprit of the cdrom timeouts seems to be -hdd ... but why? I saw the same things few weeks ago. Since then, I do not use hdd anymore (my qemu host is winXP). I remember it was better on real hardware to have the cdrom either alone on one IDE interface, or at most slave on the IDE interface if shared with a hard disk. In this case, hdc is the master. I believe qemu is really a very good hardware emulator... Indeed we can see the implication of having hdd and hdc active at the same time. :) -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Weird behaviour of mailing list?
same for me here. about 150+ messages and it keeps growing... On 8/20/06, René Korthaus [EMAIL PROTECTED] wrote: Hey, is anyone else experiencing this? Since some hours I get messages dating from February, March and April again... René Korthaus ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Problem: Keyboard dead after -loadvm
On 7/17/06, Fabrice Bellard [EMAIL PROTECTED] wrote: Sometimes I try :-) But evaluating patches takes a large amount of time and in a program like QEMU regressions are difficult to track and very easy to introduce... not all on this list do contribute patches (in my case, not much contribution at this level). But I believe we're tons of testers of incoming patches :) you're not alone to test these patches: this is what I mean... I remember the asynchronous/dma patch could be also a good candidate for insertion, if it could be updated... -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCow v2
how about also adding lzma compression for qcow ? I know how to do this inside linux kernel, but lzma'ed qcow images for windows guests could be a very nice addition too. Thank Mark for the notes. I'll look at it to see how to start a lzma patch for qcow... On 7/4/06, Fabrice Bellard [EMAIL PROTECTED] wrote: Regarding my current plans, the next qcow evolution will be the support for multiple snapshots. Each snapshot will be tagged by a label. Fabrice. -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCow v2
1) size... win30.qcow is 7.5Mb (no compress) 3.5Mb (with zlib) it should go down between 2.2Mb and 2.5Mb with lzma 2) we can use lzma in a standalone compressor, and the decompressor is pure C. So at least at the decompressor level, it's not really a dependency... 3) faster decompression... On 7/4/06, Johannes Schindelin [EMAIL PROTECTED] wrote: Hi, On Tue, 4 Jul 2006, Christian MICHON wrote: how about also adding lzma compression for qcow ? Why lzma? We already have a dependency on zlib, why not just take that? Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCow v2
how do I test it unless I implement it? Is it enough to split the qcow into the clusters, compress each one of them, then add the total files sizes ? how to split into individual clusters a qcow image ? On 7/4/06, Fabrice Bellard [EMAIL PROTECTED] wrote: Christian MICHON wrote: 1) size... win30.qcow is 7.5Mb (no compress) 3.5Mb (with zlib) it should go down between 2.2Mb and 2.5Mb with lzma Did you compare with 4 KB clusters ? If you compress the whole file it says nothing about the compression gain you will have with 4 KB blocks. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCow v2
sorry I was not clear here... On 7/4/06, Fabrice Bellard [EMAIL PROTECTED] wrote: how to split into individual clusters a qcow image ? A good approximation is to use an uncompressed qcow image, or even a raw image in which you exclude the empty clusters. Fabrice. how do I cut into the actual 4k clusters an existing qcow image ? any bash script or executable to perform this trick ? -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCow v2
ok, I used split -b 4k on a 7716864 bytes qcow. I used standard lzma compression and get 1884 7z-clusters with a grand total of 3558617 bytes (indeed the gain is small). The standard zlib qcow gave 3704180 bytes... Does it make sense to have a cluster based compression ? Indeed the actual compression is not so impressive then (zlib or not zlib based). On 7/4/06, Christian MICHON [EMAIL PROTECTED] wrote: sorry I was not clear here... On 7/4/06, Fabrice Bellard [EMAIL PROTECTED] wrote: how to split into individual clusters a qcow image ? A good approximation is to use an uncompressed qcow image, or even a raw image in which you exclude the empty clusters. Fabrice. how do I cut into the actual 4k clusters an existing qcow image ? any bash script or executable to perform this trick ? -- Christian -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCow v2
for what it's worth: qcow with lzo -9 would become 4155352 bytes (bigger than original zlib qcow). yet it's true at the compression and decompression stages that it feels faster... On 7/4/06, Elefterios Stamatogiannakis [EMAIL PROTECTED] wrote: I agree Lzma and zlib are pretty much equivalent, so there is pretty much nothing to be gained except slightly more compression. On the other hand with lzo (1) there would be quite a considerable speed improvement at the cost of compression. It could also mean that reading on the qcow format could some times be faster (with compressible data) than reading directly from the hard disk. lefteris (1) http://www.oberhumer.com/opensource/lzo/ Johannes Schindelin wrote: Hi, On Tue, 4 Jul 2006, Christian MICHON wrote: how about also adding lzma compression for qcow ? Why lzma? We already have a dependency on zlib, why not just take that? Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vl.h Makefile.target hw/pci.c hw/pcnet.c
this pcnet patch set breaks mingw/win32 build. I had to remove it from my latest cvs grab. On 7/4/06, Fabrice Bellard [EMAIL PROTECTED] wrote: Note: I commited the pcnet patch as some people might be interested by it. I was unable to use it with a Knoppix distribution of 2003 so fixes are needed. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Asking about IDE to develop Qemu
On 6/22/06, Tieu Ma Dau [EMAIL PROTECTED] wrote: Hi all, I'm working a project which develops Qemu running on MinGW/MSys but I don't know which IDE I should use to develop, to test, to debug Qemu source code: http://www.eclipse.org: generic IDE in java http://www.eclipse.org/cdt: what will make eclipse become a full C/C++ IDE -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
On 6/21/06, Fabrice Bellard [EMAIL PROTECTED] wrote: Hi, Concerning the QEMU GUI, my mind slightly evolved since my last posts on the topic: I think that a wxWidgets GUI would be the best as it is reasonnably portable and because it uses the native GUIs. If someone is interested, I am ready to try to include such a GUI in the QEMU repository even if it is not usable yet. Do you still want SDL to move out of the project ? -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
you're putting c++ inside the qemu source tree when it is not needed (yet). if SDL is common to most guest screens: I agree with you that the gui/toolkit should overlay the SDL. Yet Fabrice mentionned months ago this was not his intention, so we should respect it and (hopefully) close this long thread. On 6/16/06, Kevin F. Quinn [EMAIL PROTECTED] wrote: On Fri, 16 Jun 2006 13:45:24 +0100 Stuart Brady [EMAIL PROTECTED] wrote: On Fri, Jun 16, 2006 at 09:21:46AM +0200, Kevin F. Quinn wrote: WxWidgets (www.wxwidgets.org) provides a nice way out of this - provides a uniform API for the application developer, and local look-and-feel for each platform. WxWidgets can sit on gtk, motif, x11, win32, mac, cocoa (doesn't appear to be a qt backend yet, but no reason there couldn't be). Yes, there should be abstraction between the UI and the VM, but I think that the approach taken by xine, gstreamer, cdrecord, cdparanoia, etc. is much cleaner. You could still write a frontend with WxWidgets... I think it would be best if QEMU didn't depend on any particular toolkit, and that includes WxWidgets. I was suggesting WxWidgets as a way to avoid writing separate gui frontends for each platform (that's what WxWidgets is for). I wasn't suggesting WxWidgets be embedded into Qemu (or the other way around for that matter). If you want a pretty controller app and you want to avoid cross-platform issues WxWidgets does a lot of the work for you (much more than just gtk for example). In particular I was responding to the statement Face it, putting a GUI on something like QEMU is going to require at least a one per desktop/platform effort. I don't see any reason to hack up qemu just to put a pretty face on it. VNC support already provides an easy way to place the guest screen wherever you want if you don't like the SDL window (although I think SDL remains the best choice for the guest screen). http://code.technoplaza.net/wx-sdl/ talks about combining WxWidgets and SDL, although I don't know if that's useful. -- Kevin F. Quinn ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
