Re: [Qemu-devel] Re: Old DOS under Qemu
On 5/13/05, Ronald [EMAIL PROTECTED] wrote: I'm already using the latest FreeOSZoo windows build. This doesn't mean that it perform like Christian's or Kazu's one, you can get a try. Actually I performed some comparisons yesterday using nbench on a qemu linux guest on winxp host, and in terms of speed, my version is as good, not better, than FreeOSZoo. What I don't understand is why qemu on XP host is performing better than qemu on linux host (without kqemu of course...). Qemu on xp is around 2 or 3x faster. Am I doing something wrong here ? Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: request : qemu-smp as target
Hi, The architecture used in sparc target (sun4m) supports SMP up to a maximum of 16 CPUs. At hardware emulation level (hw/*, target-sparc/*), it would be easy to add the missing interprocessor interrupts, per-CPU counters and atomic instructions. It would also be simple to add the prom functions for starting/stopping CPUs to Proll. Maybe some days' work in total. Higher level (vl.c, cpu-exec.c) could need more work. Maybe Fabrice can enlighten us? For some reason, Sparc performance is low (1/10 of native x86 nbench) compared to x86 (2/3). Simulating SMP on a uniprocessor would only decrease performance. _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] gcc4 host support
In addition to this patch I also needed the attached patch to get MinGW
GCC 3.4.1 builds working...
...
- if (strstart(sym_name, __op_label, p)) {
+ if (strstart(sym_name, __op_label, p) ||
+strstart(sym_name, _op_label, p)) {
I'm not sure this is the right fix. Did I miss an ASM_NAME macro somewhere?
Paul
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] some observations
Hi. I am new to qemu, but I was quite successful with it so far. I have also seen some glitches, so I would like to share my experience. My system: i430VX chipset, Pentium I 200MMX, 48MB RAM, S3virge card Slackware 9.1, kernel 2.4.22 (custom compiled), glibc 2.3.2 I run qemu with the options '-hda file -m 24 -localtime'. As you can see, my hardware is even lower spec than the virtual machine qemu is emulating (a PII), therefore it is a very interesting for me to study how Windows or Linux recognize it:) I downloaded the binary package and installed it. It was nice that there is no configuration needed (compared to dosemu or wine). I also got the freedos image so I run it. It ran, but it was very limited. So I checked the image format and it looked like a plain harddisk dump. So I dd'ed my other hardisk into a file in Linux and booted that... And I was impressed. It worked like a charm. My ages-old bootmanager (System Commander) in the MBR booted and offered my system choices (MSDOS 6.22, Win95, Linux). I tried MSDOS. It booted and got me correctly into Norton commander. Then the problems began. The cursor keys were not working, they produced numbers when pressed, not cursor movement. I haven't resolved this problem till now. Any ideas? Then I tried Win95. It worked too. It booted and complained about the changed video card. I started the offered detection, but it didn't work. I will try to select the correct driver manually later. Because it is hell slow (ever seen Win95 on 386, 8MB?:)) so I didn't play with it much. It also started in some MS DOS mode for harddisks, probably not 32bit access. Otherwise, applications seem to work OK, like Far file manager or MS office 97. Then I tried linux (2.2.19) and it booted correctly too. Interestingly, the startup raid instruction benchmark choosed pIII_sse as the fastest method for the checksums. Also, hdparm segfaulted immediatelly after execution. I haven't played with the OSes too much, because it was quite slow (the docs about the 5-10x slowdown don't lie:)) so I wanted to check kqemu first. I got the qemu and kqemu sources and compiled it (gcc, 3.2.3, SDL 1.2.6). It took longer than a kernel compile, probably because it compiled all architectures (I found the configure switch later). It all went cleanly, the install too. I provided a tmpfs at /dev/shm, according to the docs. I gave it 32MB. On the first run, qemu complained that it's not enough. Why? I had to increase it to 36MB. Then, qemu -m 24 suceeded. Strange. Anyway, MSDOS run with the same bugs as before. Linux too. The kernel detected a pII cpu. But the utility x86info (it uses some other method, not /proc/cpuinfo) found the real cpu - pI. Strange. (Without kqemu, it found pII too.) I didn't notice any speed increase due to kqemu :( Is that normal? But Win95 had a serious problem. It crashed while booting with a protection fault. Then it rebooted. So, I now tried qemu with the -no-kqemu option. Win95 booted correctly. My only concern was that qemu used up space in /dev/shm, as if kqemu was in use. There is no comment in the doc files, that qemu does this without kqemu. I haven't yet tested the more advanced features like user-net and -smb. One last note, the fullscreen mode (Ctrl-Alt-f) didn't work for me in the official binary. It did nothing. But it worked in my compiled version. But only when the guest OS (e.g. Win) was in graphics mode. When I hit it in text mode, qemu crashed with a segfault. I hope, there is some value in this information for some of the developers. This program is very nice indeed. Thanks for reading till now :) Regards, Peter ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: request : qemu-smp as target
Blue Swirl wrote: Hi, The architecture used in sparc target (sun4m) supports SMP up to a maximum of 16 CPUs. At hardware emulation level (hw/*, target-sparc/*), it would be easy to add the missing interprocessor interrupts, per-CPU counters and atomic instructions. It would also be simple to add the prom functions for starting/stopping CPUs to Proll. Maybe some days' work in total. Higher level (vl.c, cpu-exec.c) could need more work. Maybe Fabrice can enlighten us? SMP est definitely possible in QEMU - a few days of work are necessary to add the missing generic support and an x86 implementation... but currently I prefer to work an other topics. Just for your information, some choices need to be made: 1) Do the CPUs share the same translation cache ? 2) The first implementation would use a cycle counter to schedule between CPUs. Is it interesting to go further and to use a host thread for each guest CPU at the expense of more locking overhead ? Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: request : qemu-smp as target
SMP est definitely possible in QEMU - a few days of work are necessary to add the missing generic support and an x86 implementation... but currently I prefer to work an other topics. Just for your information, some choices need to be made: 1) Do the CPUs share the same translation cache ? This could be very useful, but wouldn't the cache need to be indexed by physical addresses, not virtual? 2) The first implementation would use a cycle counter to schedule between CPUs. Is it interesting to go further and to use a host thread for each guest CPU at the expense of more locking overhead ? I'd skip the cycle counter at first iteration and schedule using a host timer and CPU idling. What are the things that need locking, by the way? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: request : qemu-smp as target
I guess you'd really want to simulate multiple CPUs with multiple host threads. One of the additional problems could then be memory/cache coherency. I'm not sure how much of a problem this would be in practice. If both host and guest require the same (or no) explicit SMP memory barriert it's not a problem. It the guest has stronger coherency requirements than the host we have a problem. Sparc32 architecure requires flushes and atomic instructions in critical code in Total Store Ordering mode. There is also higher performance mode requiring memory barriers called Partial Store Ordering, but I think Linux doesn't enable it. For some reason, Sparc performance is low (1/10 of native x86 nbench) compared to x86 (2/3). Simulating SMP on a uniprocessor would only decrease performance. It think x86-on-x86 user-mode uses code-copying by default. ie. it runs a lot of the the code unmodified. In my experience i386-softmmu is generally 10-15x slower than native, and arm-user is 5-10x slower. Good point. With -no-code-copy I get about 1/6 of native nbench in x86-x86, comparable to Sparc figure. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: request : qemu-smp as target
On Sat, 2005-05-14 at 14:16 +0200, Fabrice Bellard wrote: ... 2) The first implementation would use a cycle counter to schedule between CPUs. Is it interesting to go further and to use a host thread for each guest CPU at the expense of more locking overhead ? What inter processor synchronization issues are there? Could you take this a step further and use processes on different machines for each processor? (There are many shared memory implementations to choose from.) I have ignorantly implemented an SH2 emulator, but have zero understanding of an SMP system. Are there so many resources shared between the CPUs to make this a ridiculous proposition? It could make for a interesting distributed single image system. -- Joe Batt [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [Patch] target-ppc mtcrf instruction not recognized
Hi,
I have been playing with ppc-darwin-user. And I have to say that qemu-
ppc is too strict with ppc opcode validity:
On Mac OS X binary release called Tiger (or 10.4), the __bzero
function [1] contains a mtcrf, which has been translated to
0x7c901120, by Apple's as. Current qemu rejects it, saying it is
invalid. According to the IBM Specification the mtcrf instruction
[2], contains reserved flags, for which the values are unknown. qemu
assumes that those are set to 1, which is obviously wrong. The
attached patch provides a fix.
The mtcrf case might not be the only case in which such a situation
occurs. That would need a special attention, though being strict is
better than letting pass.
Pierre.
[1] http://fxr.watson.org/fxr/source/osfmk/ppc/commpage/bzero_32.s?
v=DARWIN8#L98
[2] http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/
alangref/mtcrf.htm
Index: target-ppc/translate.c
===
RCS file: /cvsroot/qemu/qemu/target-ppc/translate.c,v
retrieving revision 1.31
diff -u -r1.31 translate.c
--- target-ppc/translate.c 12 May 2005 18:46:11 - 1.31
+++ target-ppc/translate.c 14 May 2005 17:14:35 -
@@ -2123,7 +2123,7 @@
}
/* mtcrf */
-GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x00100801, PPC_MISC)
+GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x, PPC_MISC)
{
gen_op_load_gpr_T0(rS(ctx-opcode));
gen_op_store_cr(CRM(ctx-opcode));
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Patch] target-ppc mtcrf instruction not recognized
On Sat, 2005-05-14 at 19:20 +0200, Pierre d'Herbemont wrote: Hi, I have been playing with ppc-darwin-user. And I have to say that qemu- ppc is too strict with ppc opcode validity: On Mac OS X binary release called Tiger (or 10.4), the __bzero function [1] contains a mtcrf, which has been translated to 0x7c901120, by Apple's as. Current qemu rejects it, saying it is invalid. According to the IBM Specification the mtcrf instruction [2], contains reserved flags, for which the values are unknown. qemu assumes that those are set to 1, which is obviously wrong. The attached patch provides a fix. Qemu assume all reserved fields are set to zero, not 1. PowerPC specifications says: (section 8.1 of PEM) Some instructions fields are reserved or must contain a predefined value as shown in the individual instruction layouts. If a reserved field does not have all bits cleared, or if a field that must contain a particular value does not contains that value, the instruction form is invalid ... In section 4.1.3.2: Invalid forms result when a bit or openrands is coded incorrectly, for example, or when a reserved bit (shown as '0') is coded as '1'. and an attempt to execute an invalid form of an instruction either invokes the illegal instruction error handler (or program exception) or yields boundedly-undefined results. In the case of mtcrf, the PowerPC specification says the bits 11, 21 and 31 (IBM notation) _must_ be zero. This is what is described in 32 bits PEM as well as 64 bits PEM (including the latest revision dated on 31/03/2005) and the 740/750 PowerPC user manual (which is the one currently emulated by Qemu). It would be acceptable to relax the check if it would make MacOS X 10.4 boot. But in this case, only the bit 11 (which causes the problem here) should be relaxed. Then, the bit mask becomes 0x0801 (not 0x). [2] http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/alangref/mtcrf.htm This is the language reference for POWER PowerPC. Some forms described in this documentation are valid only for POWER CPUs. Please use PowerPC Environment Manual for PowerPC only specifications. -- J. Mayer [EMAIL PROTECTED] Never organized ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
