Re: [Qemu-devel] qemu & arm eabi (armel)
Paul Brook wrote: On Tuesday 26 September 2006 23:14, K. Richard Pixley wrote: Ok, then I'm confused because I'm seeing dumps just trying to run a null program. Unless there's NPTL setup stuff in crt0, I can't guess what might be going on yet. This same null binary runs on a qemu-system with suitable rootfs & kernel. The glibc startup code contains TLS initialisation that will fail on unpatched qemu. If you have applied the TLS patch there are a couple of other things that could cause problems: - Make sure it's picking up the correct target shared libraries (or link your test application statically). Done. - Try configuring qemu with --static. The default (building qemu as a shared library) seems to cause strange problems on many systems. Done. - Make sure uname -r reports at least 2.6.16 (qemu can lie for you). Ah. Hm.. ubuntu-5 is currently: [EMAIL PROTECTED]> uname -a Linux svrpixleylnx 2.6.12-10-686-smp #1 SMP Tue Jul 18 23:03:01 UTC 2006 i686 GNU/Linux Do you know why 2.6.16 would be required? (I'll see if I can't find/build a 2.6.16 system on which to try it today.) --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu & arm eabi (armel)
> Do you know why 2.6.16 would be required? (I'll see if I can't > find/build a 2.6.16 system on which to try it today.) Because arm-linux didn't get EABI support until 2.6.16 (though our toolchains may accept 2.6.14). glibc has santity checks stop applications even trying to run on kernels that are too old. As I mentioned qemu lie about the kernel version. See -r and --enable-uname-release. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu & arm eabi (armel)
Paul Brook wrote: Do you know why 2.6.16 would be required? (I'll see if I can't find/build a 2.6.16 system on which to try it today.) Because arm-linux didn't get EABI support until 2.6.16 (though our toolchains may accept 2.6.14). glibc has santity checks stop applications even trying to run on kernels that are too old. As I mentioned qemu lie about the kernel version. See -r and --enable-uname-release. I'm confused. My host kernel, (hosted on an x86 ubuntu box), is: [EMAIL PROTECTED]> uname -r 2.6.12-10-686-smp And my understanding is that there is no kernel when running qemu-user because qemu is emulating the kernel calls. What am I missing? Or where does the kernel version come into play? --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu & arm eabi (armel)
On Wednesday 27 September 2006 19:27, K. Richard Pixley wrote: > Paul Brook wrote: > >> Do you know why 2.6.16 would be required? (I'll see if I can't > >> find/build a 2.6.16 system on which to try it today.) > > > > Because arm-linux didn't get EABI support until 2.6.16 (though our > > toolchains may accept 2.6.14). glibc has santity checks stop applications > > even trying to run on kernels that are too old. > > > > As I mentioned qemu lie about the kernel version. See -r > > and --enable-uname-release. > > I'm confused. My host kernel, (hosted on an x86 ubuntu box), is: > > [EMAIL PROTECTED]> uname -r > 2.6.12-10-686-smp > > And my understanding is that there is no kernel when running qemu-user > because qemu is emulating the kernel calls. > > What am I missing? Or where does the kernel version come into play? glibc startup code checks the kernel version. If the reported version is earlier than the version it was compiled for it will terminate. When building glibc you specify a kernel version, and glibc will leave out backwards compatibility code for older kernels. The runtime check is a sanity check. It's generally better for the application to die immediately than fail subtly later on. Of course when using qemu the syscalls thatqemu emulates tend to be more important than the host kernel version. By default qemu will report the same version as the host kernel. However you can tell it to report a different version. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-i386 helper2.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard06/09/27 19:52:41 Modified files: target-i386: helper2.c Log message: enabled PSE36 for x86_64 (fix for OpenSolaris as guest) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemu&r1=1.44&r2=1.45 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-i386 cpu.h helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard06/09/27 19:54:02 Modified files: target-i386: cpu.h helper.c Log message: SMM fix for x86_64 CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemu&r1=1.37&r2=1.38 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.70&r2=1.71 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] RAM overcomittment
Hello, I'd like to know if qemu have a tool that let a VM to use more RAM than it have (when initialised). Another question is : Can we run run many VM using more RAM than the RAM installed (on the workstation)? For example I'd like to create 5 VM's who have 256MB (can use 256MB but only for a slice of time) but normally one VM use only 50MB. On the workstation I have only 512MB RAM. Is it possible to create these VM's or have we to have 5 X 256 RAM + HOST RAM = 1.5 GB installed on the workstation? I think we can save ressource by using RAM overcomittment. What do you think? Is this implemented on qemu? Or will be implemented? Thank you! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-i386 helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard06/09/27 21:31:59 Modified files: target-i386: helper.c Log message: fixed user mode emulation CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.71&r2=1.72 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RAM overcomittment
On Wednesday 27 September 2006 22:31, The MoonSeeker wrote: > Hello, > > I'd like to know if qemu have a tool that let a VM to use more RAM > than it have (when initialised). > > Another question is : Can we run run many VM using more RAM than the > RAM installed (on the workstation)? For example I'd like to create 5 > VM's who have 256MB (can use 256MB but only for a slice of time) but > normally one VM use only 50MB. On the workstation I have only 512MB > RAM. Is it possible to create these VM's or have we to have 5 X 256 > RAM + HOST RAM = 1.5 GB installed on the workstation? > > I think we can save ressource by using RAM overcomittment. What do > you think? Is this implemented on qemu? Or will be implemented? qemu is just like any other application. It is only limited by how much virtual memory your OS can provide. ie. if you have sufficient swap you can have as many qemu instances using as much memory as you want. qemu is currently limits each guest to 2Gb ram. This is independent of how much physical memory the host has. Note that modern OS (everything except DOS) generally use all available ram. Telling qemu to use more memory than you have physical ram is liable to cause heavy swapping. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RAM overcomittment
Hello, TM> Another question is : Can we run run many VM using more RAM than the TM> RAM installed (on the workstation)? For example I'd like to create 5 TM> VM's who have 256MB (can use 256MB but only for a slice of time) but TM> normally one VM use only 50MB. On the workstation I have only 512MB TM> RAM. Is it possible to create these VM's or have we to have 5 X 256 TM> RAM + HOST RAM = 1.5 GB installed on the workstation? TM> I think we can save ressource by using RAM overcomittment. What do TM> you think? Is this implemented on qemu? Or will be implemented? It seems to me that no change to QEMU is needed for this; it should already be supported by your host OS. Simply allocate the memory that you want (256mb, for example) for each virtual machine. Depending on how many virtual machines you have open at once, as well as the memory used by the host OS and any other applications you're running, the host OS will fit the as much as it can in the physical ram, and automatically swap out the excess allocated memory to disk. However, swapping (using virtual memory) will be a huge performance killer. It will affect the performance of your host OS and all applications, as well as for your QEMU instances. -- James Funny quotes: "There are 10 types of people in the world. Those who understand binary, and those who don't." -- Unknown "A computer once beat me at chess, but it was no match for me at kick boxing." -- Emo Philips ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RAM overcomittment
Le 27 sept. 06 à 23:41, Paul Brook a écrit :qemu is just like any other application. It is only limited by how much virtual memory your OS can provide. ie. if you have sufficient swap you can have as many qemu instances using as much memory as you want. qemu is currently limits each guest to 2Gb ram. This is independent of how much physical memory the host has. Note that modern OS (everything except DOS) generally use all available ram. Telling qemu to use more memory than you have physical ram is liable to cause heavy swapping. Ok but some virtual solution like openVZ allow you run more VM than the memory installed. By example, with openVZ I can create 10 Virtual Machine who have a limite fixe to 200 MB but have guaranteed RAM of 20MB. With qemu I need to have 10 X 200MB for VM's + 128 MB host of RAM installed on the work station...I think we can Save ressource because in the most case, the VM's will never use the 200MB. I think it will be a nice if qemu implemented a tool that let use exceed this limitation.I can show you an application domain :For my diploma project, I have to create a network simulator but with these limitation I can't use qemu. Because if would like to simulate 20 workstions I need 20 X 128 MB = 2560 MB of RAM... + host RAM!!! But in the simulation, the VM's never will use all of ressource..What do you?Thank you___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RAM overcomittment
Le 27 sept. 06 à 23:57, James Olsen a écrit :It seems to me that no change to QEMU is needed for this; it should already be supported by your host OS. Simply allocate the memory that you want (256mb, for example) for each virtual machine. Depending on how many virtual machines you have open at once, as well as the memory used by the host OS and any other applications you're running, the host OS will fit the as much as it can in the physical ram, and automatically swap out the excess allocated memory to disk. However, swapping (using virtual memory) will be a huge performance killer. It will affect the performance of your host OS and all applications, as well as for your QEMU instances. The problem is the swaping even the VM don't need all of ressource assigned... We lost RAM...By example you run 4 VM who have 256 MB (assigned with -M option) but just use 56MB in most of time.. with qemu we lost 4 X (256-56MB) = 800MB of RAM!Somme other virtualization solution like OpenVz and VServer let this RAM overcommitment. On a VM when you make the command free you can show all RAM installed on the workstation, and with file configuration you set the guaranteed RAM (in this case 56MB) and the limite (in this case 256MB). The limit can be reach only for a cup of time (when VM need ressource..)!!!Do you understant what I mean?I'd like to create an open network simulator based on qemu but this restriction can't let me use qemu...What do you think? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RAM overcomittment
> Ok but some virtual solution like openVZ allow you run more VM than > the memory installed. By example, with openVZ I can create 10 Virtual > Machine who have a limite fixe to 200 MB but have guaranteed RAM of > 20MB. With qemu I need to have 10 X 200MB for VM's + 128 MB host of > RAM installed on the work station... Nonsense. > I think we can Save ressource because in the most case, the VM's will > never use the 200MB. I think it will be a nice if qemu implemented a > tool that let use exceed this limitation. Like I said, qemu is just like any other application. It's up to your host OS to handle management of physical RAM. There's no need for additional tools. > For my diploma project, I have to create a network simulator but with > these limitation I can't use qemu. Because if would like to simulate > 20 workstions I need 20 X 128 MB = 2560 MB of RAM... + host RAM!!! > But in the simulation, the VM's never will use all of ressource.. Just add a few Gb swap. Even the oldest of machines shouldn't have any problem adding say 4Gb swap. Depending on your OS settings you may not even need to do that. Besides which modern entry-level PCs should be able to take 2Gb ram without significant problems. Workstations with 8Gb aren't that hard to come by. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RAM overcomittment
> > However, swapping (using virtual memory) will be a huge performance > > killer. It will affect the performance of your host OS and all > > applications, as well as for your QEMU instances. > > The problem is the swaping even the VM don't need all of ressource > assigned... We lost RAM... You need to fix your host OS then. If the guest isn't using the memory it shouldn't be swapped in. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RAM overcomittment
Hi, On 27/09/06, The MoonSeeker <[EMAIL PROTECTED]> wrote: Ok but some virtual solution like openVZ allow you run more VM than the memory installed. By example, with openVZ I can create 10 Virtual Machine who have a limite fixe to 200 MB but have guaranteed RAM of 20MB. With qemu I need to have 10 X 200MB for VM's + 128 MB host of RAM installed on the work station... I think we can Save ressource because in the most case, the VM's will never use the 200MB. I think it will be a nice if qemu implemented a tool that let use exceed this limitation. How would you implement that? I can show you an application domain : For my diploma project, I have to create a network simulator but with these limitation I can't use qemu. Because if would like to simulate 20 workstions I need 20 X 128 MB = 2560 MB of RAM... + host RAM!!! But in the simulation, the VM's never will use all of ressource.. Then give the VMs only as much as they will use (note that VMs can also have swap) or use host swap. Regards, -- balrog 2oo6 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RAM overcomittment
Le 28 sept. 06 à 00:19, Paul Brook a écrit :For my diploma project, I have to create a network simulator but with these limitation I can't use qemu. Because if would like to simulate 20 workstions I need 20 X 128 MB = 2560 MB of RAM... + host RAM!!! But in the simulation, the VM's never will use all of ressource.. Just add a few Gb swap. Even the oldest of machines shouldn't have any problem adding say 4Gb swap. Depending on your OS settings you may not even need to do that. Besides which modern entry-level PCs should be able to take 2Gb ram without significant problems. Workstations with 8Gb aren't that hard to come by. If we have enough swap memory, You are saying that is possible to run 20 MV's with option -M equal 128MB? For example the VM's (20) normally use 20MB and I have 512Mb of RAM on my workstation, what's about the performance? RAM used = 20X20MB + 112MB for host = 512MB nothing is swap???Thank you___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] RAM overcomittment
On Wednesday 27 September 2006 23:53, The MoonSeeker wrote: > Le 28 sept. 06 à 00:19, Paul Brook a écrit : > >> For my diploma project, I have to create a network simulator but with > >> these limitation I can't use qemu. Because if would like to simulate > >> 20 workstions I need 20 X 128 MB = 2560 MB of RAM... + host RAM!!! > >> But in the simulation, the VM's never will use all of ressource.. > > > > Just add a few Gb swap. Even the oldest of machines shouldn't have > > any problem > > adding say 4Gb swap. Depending on your OS settings you may not even > > need to > > do that. > > If we have enough swap memory, You are saying that is possible to run > 20 MV's with option -M equal 128MB? Yes, exactly. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PowerPC Decrementer Clock Rate
Hi, Does the time-base setting below signify that the PowerPC Decrementer is at 100MHz or is it the CPU? This isn't completely obvious because sometimes you have something like 4 bus clocks per decrementer increment. ... ppc_prep.c /* Set time-base frequency to 100 Mhz */ cpu_ppc_tb_init(env, 100UL * 1000UL * 1000UL); ... Thanks, Ely Soto Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re[2]: [Qemu-devel] qemu & arm eabi (armel)
Hello Paul, Wednesday, September 27, 2006, 9:38:57 PM, you wrote: > On Wednesday 27 September 2006 19:27, K. Richard Pixley wrote: [] > Of course when using qemu the syscalls thatqemu emulates tend to be more > important than the host kernel version. By default qemu will report the same > version as the host kernel. However you can tell it to report a different > version. Excuse me for stupid question, but how? I hit that issue some time ago, and ended up patching glibc. Now it is here again, and I again did qemu-arm --help, read the doc, grepped it, etc. And well, IIRC, on that first occasion I even looked at the qemu source, to see if it can do that. All in vain. What did I miss? > Paul Thanks, -- Paulmailto:[EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu & arm eabi (armel)
> > Of course when using qemu the syscalls thatqemu emulates tend to be more > > important than the host kernel version. By default qemu will report the > > same version as the host kernel. However you can tell it to report a > > different version. > > Excuse me for stupid question, but how? As I mentined in an earlier mail, you can use the -r qemu commandline option, or configure qemu with --enable-uname-release. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] w2k net problems since update from sunday
On Tue, 2006-09-26 at 08:44 +0200, Jens Arm wrote: > Hi > > Since the update from sunday w2k can load the net driver, but it can not send > or receive > pakets. W2k can not get an IP from the usernet-dhcp. > > I start qemu like this: qemu -m 384 disk.dsk I'm seeing this as well with recent cvs. It appears to be triggered when acpi is enabled (with -no-acpi it works). Tested with a few guests and user mode networking: debian sarge w/ 2.4 kernel: network works debian sarge w/ 2.6 kernel: nic detected - dhcp and static settings fail windows 2k/xp: nic detected - dhcp and static settings fail ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
