Re: [Qemu-devel] Old DOS under Qemu
On 5/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I've been trying to install various old versions of DOS under Window's v0.70 > of qemu from FreeOSZoo. > > And since so few people appear to be using the Windows version, I've been > making a point to do as much testing as I can, with as wide a variety of > operating systems as I can find. > > >From version 5 on up, I only have a few problems (Which I've already > reported.) I want to come back on the last item. I have made images of my 15y old 720k floppies, and jumped back to 1991 this morning. - 3x720k for DOS5.0 - 7x720k for win3.00a - 7x720k for works2.0 all original, not warez. Cost a bunch back in 1991 :( I tried a few things: - install dos: ok - install win: ok - mouse: ok, no change of speed on qemu070/XPhost - floppies 720k: ok. The catch to format them is to either quick format them, not in high density. Inside win3.00a, it works like a breeze. win3.00a even recognise 18M of ram to play with. I've seen no problem whatsoever. Do you want my bins jeebs ? Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] $B?75,EPO?$NJ}$O(B10000$B1_J,L5NA(B
$B0lK|1_J,!*40A4L5NA$G;HMQ(BOK $B"#:#$J$i4V$K9g$&(BW$B%A%c%s%9!*L5NA%]%$%s%H%"%C%W3Z$7$5(B100$BG\!*"#(B $B"([EMAIL PROTECTED](B $B0l0L!'5U1g!J(B189$BL>EPO?!K(B $BFs0L!'1g8r!J(B429$BL>EPO?!K(B $B;00L!'(BSM$B5U1g!J(B243$BL>EPO?!K(B $B;M0L!'%;%U%l!J(B1038$BL>EPO?!K(B $B8^0L!'ITNQ!J(B2421$BL>EPO?!K(B $BO;0L!'%F%l%(%C%A!J(B3463$BL>EPO?!K(B $B!&(B $B!&(B $B!&(B $B0lK|1_J,40A4L5NA$G$*;n$7$O(B $B"-"-"-(B http://awg.webchu.com/?summer23 $BB~:#!*?75,EPO?$7$?J}$K$OL5NA$G(B10,000$B1_J,$4MxMQ=PMh$^$9!#(B $B!ZL5NA%]%$%s%HFb$G==J,$K%Q!<%H%J!<$rC5$9;v$,=PMh$^$9!#![(B $B"((B18$B:P0J>e$NHkL)87http://awg.webchu.com/?summer23 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= $B"((B18$B:PL$K~$N$4MxMQ1sN82<$5$$!#(B $B:#8e!"%a!<%k$Nl9g$O2<5-(BURL$B$KJV?.2<$5$$!#(B [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Old DOS under Qemu
I just wonder about 1 thing: In every test - have you created a new hard drive image prior to running QEMU? I would suggest creating new hard drive images before using QEMU and use this new hard drive image for each test. Also, my guess is that some of your floppy images are actually a compressed Disk Plus Pro/WinImage files. I suggest you download winimage from http://www.winimage.com and extract the boot floppies to a new image file (simply open them with winimage and then click save as, and save them as IMA file). Hope this helps, Hetz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Old DOS under Qemu
Christian; > >From version 5 on up, I only have a few problems (Which I've already > > reported.) >I want to come back on the last item. I have made images of my 15y old 720k >floppies, and jumped back to 1991 this morning. The only problems I've noticed with newer DOS's are (right off the top of my head) 1) mouse driver problem failing. (In the Ghost backup floppy. Standard microsoft driver.) Also, Ghost itself fails with the same error. This disk definetly works under real hardware because I use it. 2) DrDos 7.03 (?) having trouble detecting the key during installation. Or maybe the floppy change... 3) Mouse driver in FreeDos hangs up. 4) Some of them saying that A20 is already enabled. That shouldn't start up like that. I think it's supposed to be disabled by default. 5) The mouse rate on my host wasn't always exactly like it originally was. That was a big problem a few months ago. I had a 'dirty' copy of XP and was using the latest Logitech mouse driver. I suspect it was the mouse driver, actually. I recently reinstalled and I'm using the default driver in XP, and most of those problems immediately disappeared. However, there have been a couple times when I'd shut qemu down and my host mouse driver seemed just a wee bit slower than it should be. It'd test it, and then reset the speed and test it again, and it seemed like it was a speed mark too slow. But, for the moment, I'm willing to say it was my imagination. It must have been the Logitech mouse driver causing so much problem before. (Whatever the cause though, it was *definetly* repeatable. It wasn't an occasional problem.) There may have been a few other issues that I've reported, but right off hand I can't remember them. Plus all the standard stuff, such as the cd change problem, etc. etc. >- floppies 720k: ok. The catch to format them is to either quick format >them, >not in high density. Inside win3.00a, it works like a breeze. Qemu has problems dealing with older size floppies. It should check the size and use that as an indicator what it's supposed to be. (Or add yet another command line switch.) Qemu could get fancy and start specifying all storts of options for custom disks, etc. but I don't know if the BIOS would support them or not. (Shame the bios isn't written for easier hacking. And it's a shame that qemu & bochs can't handle a larger bios so it could be extended, config screens added, etc. etc.) Probably be easier to just check for disk sizes of 160k, 180k, 320k, 360k, 720k, 1.2m, 1.44m, 2.88m, 820k, 1.72m and 1.68m and set the hardware type accordingly at startup. (Again, I don't know what sizes the bios can support.) (Actually, if you check the disk sizes, you may have to allow a few k-bytes either way, since some disk images may not be the exact byte size, even though they should be.) >I've seen no problem whatsoever. Do you want my bins jeebs ? Thanks for the offer, but I already own Dos 5 and Win300a (although admittedly the images I'm using came from a friend, since I no longer have a 5.25" floppy, and didn't make images of them back then.) I am still looking (for qemu testing purposes, of course, since I wouldn't try to install this on my real computer[laugh]) for a valid, known good copy of ms-dos 3.3, pc-dos 4.01, and pc-dos 6.10. And maybe pcdos 7 and 2000. And I wouldn't be opposed to Win/286 or Win/386 either. The warez copies I have could either be damaged or hardware specific. It wasn't uncommon for dos 3.x to be modified for a specific brand of computer or even a specific machine. And although it's interesting that the copies I have behave differently in Bochs than in Qemu, I'm definetly willing to say that due to their warez nature, the results may not be accurate or significant. I guess, realistically, that my testing old OS's may not really help qemu development all that much, but since my home computer is older and not as fast as most people's, I don't really want to spend hours and hours and hours trying to install XP or Win2k3 or something, just to have it fail. If the qemu accelerator modules worked under Windows (and actually improved the speed, since qvm86 seems to slow qemu down!), then I might. But for now, testing older stuff is all that I have time for. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] gcc4 host support
On Wednesday 11 May 2005 22:04, Paul Brook wrote:
> The attached patch adds support for gcc4 x86 and x86_64 hosts.
This time with the correct patch attached.
Paul
Index: dyngen-exec.h
===
RCS file: /cvsroot/qemu/qemu/dyngen-exec.h,v
retrieving revision 1.25
diff -u -p -r1.25 dyngen-exec.h
--- dyngen-exec.h 24 Apr 2005 18:01:56 - 1.25
+++ dyngen-exec.h 11 May 2005 20:38:33 -
@@ -155,7 +155,12 @@ extern int printf(const char *, ...);
#endif
/* force GCC to generate only one epilog at the end of the function */
+#if defined(__i386__) || defined(__x86_64__)
+/* Also add 4 bytes of padding so that we can replace the ret with a jmp. */
+#define FORCE_RET() asm volatile ("nop;nop;nop;nop");
+#else
#define FORCE_RET() asm volatile ("");
+#endif
#ifndef OPPROTO
#define OPPROTO
@@ -205,12 +210,19 @@ extern int __op_jmp0, __op_jmp1, __op_jm
#endif
#ifdef __i386__
-#define EXIT_TB() asm volatile ("ret")
-#define GOTO_LABEL_PARAM(n) asm volatile ("jmp " ASM_NAME(__op_gen_label) #n)
+/* Dyngen will replace hlt instructions with a ret instruction. Inserting a
+ ret directly would confuse dyngen. */
+#define EXIT_TB() asm volatile ("hlt")
+/* Dyngen will replace cli with 0x9e (jmp).
+ We generate the offset manually. */
+#define GOTO_LABEL_PARAM(n) \
+ asm volatile ("cli;.long " ASM_NAME(__op_gen_label) #n " - 1f;1:")
#endif
#ifdef __x86_64__
-#define EXIT_TB() asm volatile ("ret")
-#define GOTO_LABEL_PARAM(n) asm volatile ("jmp " ASM_NAME(__op_gen_label) #n)
+/* The same as i386. */
+#define EXIT_TB() asm volatile ("hlt")
+#define GOTO_LABEL_PARAM(n) \
+ asm volatile ("cli;.long " ASM_NAME(__op_gen_label) #n " - 1f;1:")
#endif
#ifdef __powerpc__
#define EXIT_TB() asm volatile ("blr")
Index: dyngen.c
===
RCS file: /cvsroot/qemu/qemu/dyngen.c,v
retrieving revision 1.40
diff -u -p -r1.40 dyngen.c
--- dyngen.c 27 Apr 2005 19:55:58 - 1.40
+++ dyngen.c 11 May 2005 20:38:33 -
@@ -32,6 +32,8 @@
#include "config-host.h"
+//#define DEBUG_OP
+
/* NOTE: we test CONFIG_WIN32 instead of _WIN32 to enabled cross
compilation */
#if defined(CONFIG_WIN32)
@@ -1343,6 +1345,639 @@ int arm_emit_ldr_info(const char *name,
#endif
+#if defined(HOST_I386) || defined(HOST_X86_64)
+
+/* This byte is the first byte of an instruction. */
+#define FLAG_INSN (1 << 0)
+/* This byte has been processed as part of an instruction. */
+#define FLAG_SCANNED (1 << 1)
+/* This instruction is a return instruction. Gcc cometimes generates prefix
+ bytes, so may be more than one byte long. */
+#define FLAG_RET (1 << 2)
+/* This is either the target of a jump, or the preceeding instruction uses
+ a pc-relative offset. */
+#define FLAG_TARGET (1 << 3)
+/* This is a magic instruction that needs fixing up. */
+#define FLAG_EXIT (1 << 4)
+#define MAX_EXITS 5
+
+static void
+bad_opcode(const char *name, uint32_t op)
+{
+error("Unsupported opcode %0*x in %s", (op > 0xff) ? 4 : 2, op, name);
+}
+
+/* Mark len bytes as scanned, Returns insn_size + len. Reports an error
+ if these bytes have already been scanned. */
+static int
+eat_bytes(const char *name, char *flags, int insn, int insn_size, int len)
+{
+while (len > 0) {
+/* This should never occur in sane code. */
+if (flags[insn + insn_size] & FLAG_SCANNED)
+error ("Overlapping instructions in %s", name);
+flags[insn + insn_size] |= FLAG_SCANNED;
+insn_size++;
+len--;
+}
+return insn_size;
+}
+
+static void
+trace_i386_insn (const char *name, uint8_t *start_p, char *flags, int insn,
+ int len)
+{
+uint8_t *ptr;
+uint8_t op;
+int modrm;
+int is_prefix;
+int op_size;
+int addr_size;
+int insn_size;
+int is_ret;
+int is_condjmp;
+int is_jmp;
+int is_exit;
+int is_pcrel;
+int immed;
+int seen_rexw;
+int32_t disp;
+
+ptr = start_p + insn;
+/* nonzero if this insn has a ModR/M byte. */
+modrm = 1;
+/* The size of the immediate value in this instruction. */
+immed = 0;
+/* The operand size. */
+op_size = 4;
+/* The address size */
+addr_size = 4;
+/* The total length of this instruction. */
+insn_size = 0;
+is_prefix = 1;
+is_ret = 0;
+is_condjmp = 0;
+is_jmp = 0;
+is_exit = 0;
+seen_rexw = 0;
+is_pcrel = 0;
+
+while (is_prefix) {
+op = ptr[insn_size];
+insn_size = eat_bytes(name, flags, insn, insn_size, 1);
+is_prefix = 0;
+switch (op >> 4) {
+case 0:
+case 1:
+case 2:
+case 3:
+if (op == 0x0f) {
+/* two-byte opcode. */
+op = ptr[insn_size];
+insn_size = eat_bytes(name, flags, insn, insn_size, 1);
+switch (op >> 4) {
+case 0:
Re: [Qemu-devel] Old DOS under Qemu
On Thursday, May 12, 2005, 18:25:22, [EMAIL PROTECTED] wrote: > 4) Some of them saying that A20 is already enabled. That shouldn't start up > like that. I think it's supposed to be disabled by default. I've seen that on real hardware with DR-DOS on Maxtor PowerMax boot floppy, so it's probably not a Qemu problem. -- < Jernej Simoncic ><><><><>< http://deepthought.ena.si/ > Any sufficiently advanced technology is indistinguishable from magic. -- A. C. Clarke's Third Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Old DOS under Qemu
> >I've seen no problem whatsoever. Do you want my bins jeebs ? > > Thanks for the offer, but I already own Dos 5 and Win300a (although > admittedly the images I'm using came from a friend, since I no longer have a > 5.25" floppy, and didn't make images of them back then.) > euh... I only meant sharing my compiled version of qemu. Sorry it was interpreted wrongly. The offer still stands :) The rest of the explaination is clear. Too bad I don't have a mouse floppy driver anymore ??? Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows XP Home on qemu 0.6.0 and Mac OS X 10.3.8
sorry for replying so late... > > If he used the installer from Free OS Zoo, this would seem to indicate > > he doesn't know which compile options were used. That's it, I didn't compile qemu myself. > > Are you suggesting that his emulator is running slowly because it is > > repeatedly attempting and failing to use the accelerated kernel > > interface? Hm... the emulator did work, but I can't tell if any part was failing. I could not find any evidence in the log files. I'll give an update as soon as I will have tried Win98. Martin ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-ppc translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 05/05/12 18:46:12 Modified files: target-ppc : translate.c Log message: dcbz fix (Jocelyn Mayer) CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/target-ppc/translate.c.diff?tr1=1.30&tr2=1.31&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] New images on www.freeoszoo.org
Hello everybody. ...just to announce I've put the OpenBSD 3.7 x86 and NetBSD 2.0.2 x86 images for qemu on the freeoszoo.org... Happy downloading! :-) Stefano ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Can't compile on ubuntu 5.04 amd64
Hi! I can't compile qemu on my Ubuntu 5.04 Amd64, after a bit of work it stops compilation with a: for d in i386-user arm-user armeb-user sparc-user ppc-user i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu; do \ make -C $d all || exit 1 ; \ done make[1]: Entering directory `/prateria/tmp/qemu-0.7.0/i386-user' gcc-3.4 -g -Wl,-T,/prateria/tmp/qemu-0.7.0/x86_64.ld -o qemu-i386 elfload.o main.o syscall.o mmap.o signal.o path.o osdep.o thunk.o vm86.o libqemu.a gdbstub.o -lm /usr/bin/ld:/prateria/tmp/qemu-0.7.0/ x86_64.ld:62: parse error collect2: ld returned 1 exit status make[1]: *** [qemu-i386] Error 1 make[1]: Leaving directory `/prateria/tmp/qemu-0.7.0/ i386-user' make: *** [all] Error 1 As you can see it seems a ld error. My binutils version is 2.15. To configure I used the trivial: ./configure Playing a bit with configure, if I do: ./configure --target-list="x86_64-softmmu i386-softmmu" I can compile a working qemu: so is the i386-user target that creates problems... The only problem I have with these binaries is that networking doesn't work (neiter usermode nor tun/tap), but looking in the ML archives I found it is a know amd64 issue. -- "Uhm... l'ho detto o l'ho solo pensato?" .::. Ziabice aka Luca Gambetta .::. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Old DOS under Qemu
I originally was creating a new hard drive image. (Actually, I was just copying one I already had, but same result.) Plus in other tests before I did the original post, I sometimes unpartitioned and repartitioned, reformatted, etc. A variety. Later, when I did the retests with bochs vs qemu, it was getting late and I was getting tired, so I just used an existing partitioned image and simply reformatted it for each test. So the only thing that was being kept was the partioning, which didn't seem to cause a problem with anything. As for the floppy images, they are all raw, uncompressed images. Otherwise the floppy wouldn't boot at all. I did just run a couple new tests. With fresh, unpartitioned, unformated disks. I can now get Dell Dos 3.30 to install and boot from C: Dos 3.20 still fails in both qemu and bochs. Dos 4.01 behaves a little differently, depending on its mood. Sometimes it'll fail during the boot floppy stage. Other times it'll fail when booting from C, sometimes with Qemu giving a fatal error and sometimes not. I may get yet more odd results if I used a seperate boot floppy (that presumably works) instead of the install disks. Some of these problems and inconsistancies may come down to: 1) Bugs in the original OS. 2) The OS not liking the newer hardware of Bochs & Qemu 3) The OS being customized for specific hardware, and doesnt like Bochs or Qemu. 4) The OS being a bit more picky about the partitioning and formatting than newer versions. 5) The OS being warez of unknowned origin. I'm beginning to suspect that number 5 is a major factor... ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Old DOS under Qemu
>euh... I only meant sharing my compiled version of qemu. >Sorry it was interpreted wrongly. The offer still stands :) I'm already using the latest FreeOSZoo windows build. There hasn't been any patches posted since it was built. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] gcc4 host support
On 5/12/05, Paul Brook <[EMAIL PROTECTED]> wrote:
> On Wednesday 11 May 2005 22:04, Paul Brook wrote:
> > The attached patch adds support for gcc4 x86 and x86_64 hosts.
>
> This time with the correct patch attached.
Hello, I can't build qemu under gcc4.0.0 with your patch and using -O2.
I get :
/home/pterjan/rpm/BUILD/qemu-0.7.0/target-i386/ops_sse.h: In function
'op_pshufw_mmx':
/home/pterjan/rpm/BUILD/qemu-0.7.0/target-i386/ops_sse.h:574: error:
unable to find a register to spill in class 'GENERAL_REGS'
/home/pterjan/rpm/BUILD/qemu-0.7.0/target-i386/ops_sse.h:574: error:
this is the insn:
(insn:HI 18 17 19 0
/home/pterjan/rpm/BUILD/qemu-0.7.0/target-i386/ops_sse.h:569 (set
(strict_low_part (subreg:HI (reg/v:DI 63 [ r ]) 0))
(mem/s/j:HI (plus:SI (mult:SI (reg:SI 64)
(const_int 2 [0x2]))
(reg/v/f:SI 59 [ s ])) [0 ._w S2 A16])) 41
{*movstricthi_1} (insn_list:REG_DEP_TRUE 16 (insn_list:REG_DEP_TRUE 12
(insn_list:REG_DEP_TRUE 53 (nil
(expr_list:REG_DEAD (reg:SI 64)
(nil)))
/home/pterjan/rpm/BUILD/qemu-0.7.0/target-i386/ops_sse.h:574: confused
by earlier errors, bailing out
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] gcc4 host support
On Thursday 12 May 2005 23:13, Pascal Terjan wrote:
> On 5/12/05, Paul Brook <[EMAIL PROTECTED]> wrote:
> > On Wednesday 11 May 2005 22:04, Paul Brook wrote:
> > > The attached patch adds support for gcc4 x86 and x86_64 hosts.
> >
> > This time with the correct patch attached.
>
> Hello, I can't build qemu under gcc4.0.0 with your patch and using -O2.
> I get :
> /home/pterjan/rpm/BUILD/qemu-0.7.0/target-i386/ops_sse.h: In function
> 'op_pshufw_mmx':
> /home/pterjan/rpm/BUILD/qemu-0.7.0/target-i386/ops_sse.h:574: error:
> unable to find a register to spill in class 'GENERAL_REGS'
> /home/pterjan/rpm/BUILD/qemu-0.7.0/target-i386/ops_sse.h:574: error:
> this is the insn:
> (insn:HI 18 17 19 0
> /home/pterjan/rpm/BUILD/qemu-0.7.0/target-i386/ops_sse.h:569 (set
> (strict_low_part (subreg:HI (reg/v:DI 63 [ r ]) 0))
> (mem/s/j:HI (plus:SI (mult:SI (reg:SI 64)
> (const_int 2 [0x2]))
> (reg/v/f:SI 59 [ s ])) [0 ._w S2 A16])) 41
> {*movstricthi_1} (insn_list:REG_DEP_TRUE 16 (insn_list:REG_DEP_TRUE 12
> (insn_list:REG_DEP_TRUE 53 (nil
> (expr_list:REG_DEAD (reg:SI 64)
> (nil)))
> /home/pterjan/rpm/BUILD/qemu-0.7.0/target-i386/ops_sse.h:574: confused
> by earlier errors, bailing out
This is a gcc bug. See gcc.gnu.org/PR16185.
Basically gcc doesn't like doing 64-bit arithmetic on a target with only three
32-bit registers (We use the other 4 registers to hold the guest CPU state).
You can hack around this by not holding the guest cpu state in registers, but
this incurs a significant speed penalty.
Paul
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] We want to example qemu and the accel-module in our distribution.
Dear qemu developers. (B (BWe are a Linux distributer called Red Flag Software from China. (BWe want to redistribute qemu + accelerator module built-in in our (Bsystem called Red Flag Server System. (B (BWe got a project need Windows XP running as a virtual machine on our system. (BBut Xen can't support other OS except Linux and NetBSD right now$B!#(B (B (BWe checked bochs, vmware and qemu. (BBochs need speed up and XP support, and Vmware isn't free software and (Bwe don't want to build it into our system. (B (BQemu with Accelerator Module works really fine on our system. (B (BSo, We need your authorized for commercial use if we done the project. (B (BThank you for your hard works. (B (B--- (BXuqing Kuang$B!J([EMAIL PROTECTED](B (BRed Flag Linux Server Development Team (B (Bwww.redflag-linux.com (Bwww.asianux.com (B (B (B___ (BQemu-devel mailing list (BQemu-devel@nongnu.org (Bhttp://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] We want to example qemu and the accel-module in our distribution.
On Fri, May 13, 2005 at 11:14:59AM +0800, Xuqing Kuang wrote: > Dear qemu developers. > > We are a Linux distributer called Red Flag Software from China. > We want to redistribute qemu + accelerator module built-in in our > system called Red Flag Server System. > > We got a project need Windows XP running as a virtual machine on our system. > But Xen can't support other OS except Linux and NetBSD right now$B!#(B > > We checked bochs, vmware and qemu. > Bochs need speed up and XP support, and Vmware isn't free software and > we don't want to build it into our system. > > Qemu with Accelerator Module works really fine on our system. > > So, We need your authorized for commercial use if we done the project. > > Thank you for your hard works. Why not choose QEMU + QVM86, The QVM86 do same thing with accelerator module, but it is Open Source Project. https://savannah.nongnu.org/projects/qvm86/ qvm86 is a kernel module to provide x86 virtualisation capabilities for the qemu emulator. Virtualisation allows "emulated" code to be run natively on the host cpu, using the CPU protection mechanisms to intercept and emulate priveleged events. But I think you'd better have donation some money to QVM86 and QEMU project. I'm also in china. :) -- Hu Gang .-. /v\ // \\ Linux User /( )\ [204016] GPG Key ID ^^-^^ http://soulinfo.com/~hugang/hugang.asc ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] We want to example qemu and the accel-module in our distribution.
Commenting for Bochs: In order to get XP to run in Bochs, you need to set the IPS insanely high. I forgot how high, but the documentation says it. -- Mike ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] We want to example qemu and the accel-module in ourdistribution.
>Why not choose QEMU + QVM86, The QVM86 do same thing with accelerator >module, but it is Open Source Project. Because at the moment, qvm86 doesn't work well. Still has bugs and limitations. And it actually seems to be *slower* than qemu without it. Or at least not much faster. That's based on the only Windows cvs build that had qvm86 with it. (Still available from the club-internet.fr Win daily build mirror.) I assume the linux build behaves the same, since it is based on the same core routines and techniques. That seems to be the impression I get from the qemu users forum, anyway. I'm sure it could be significantly improved, but at the moment there are only a couple people working occasionally on it. So it's not something you can depend on being vastly improved on in the next few weeks. (To be honest, I suspect that the qvm86 techniques didn't work as well as the author originally expected / hoped. Just my feeling.) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
