qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] qemu-fast - a better howto?
@ 2004-03-01 17:30 Gabriel Guzmics
  2004-03-02  0:17 ` Gabriel Ebner
  0 siblings, 1 reply; 3+ messages in thread
From: Gabriel Guzmics @ 2004-03-01 17:30 UTC (permalink / raw)
  To: qemu-devel

Well, I managed to run normal Qemu, using a gentoo machine and my win98se cd

What I didnt manage is to compile qemu-fast

What about a some better howto about qemu-fast (how to set up, etc.)
and: does the kernel-configuration differ somehow with 2.6.x kernels?

I searched around on the qemu site, but didnt find anything detailed about it.

also, it is said, that I should look up at bochs for win98 graphics driver 
configuration. (win98 dont find any, VGA, SVGA and so on dont work)

but i didnt find any information about that on the bochs site (maybe i'm 
blind)

some links would be cool. ;)

-----
sorry for spammin'
g.g.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] qemu-fast - a better howto?
  2004-03-01 17:30 Gabriel Guzmics
@ 2004-03-02  0:17 ` Gabriel Ebner
  0 siblings, 0 replies; 3+ messages in thread
From: Gabriel Ebner @ 2004-03-02  0:17 UTC (permalink / raw)
  To: cyb.org, qemu-devel

Hello,

Am Montag, 1. März 2004 18:30 schrieb Gabriel Guzmics:
> What I didnt manage is to compile qemu-fast
Do you also get the following error?

gcc  -static -Wl,-T,/home/gebner/tmp/qemu/i386-vl.ld  -o qemu-fast vl.o 
block.o ide.o vga.o sb16.o dma.o oss.o fdc.o osdep.o sdl.o libqemu.a  -lm 
-L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread -lm -ldl -lasound 
-L/usr/X11R6/lib -lX11 -lXext -laa -L/usr/lib -Wl,-rpath,/usr/lib -laa -lm 
-L/usr/X11R6/lib -lX11 -lslang
/usr/lib/libSDL.a(SDL_x11gl.lo)(.text+0x8d6): In function 
`X11_GL_LoadLibrary':
: warning: Using 'dlopen' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking
/usr/X11R6/lib/libX11.a(x11trans.o)(.text+0xfe0): In function 
`_X11TransSocketINETConnect':
: warning: Using 'getaddrinfo' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
BFD 2.14.90.0.7 20031029 assertion fail elf.c:3460
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
BFD 2.14.90.0.7 20031029 assertion fail elf.c:3460
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
BFD 2.14.90.0.7 20031029 assertion fail elf.c:3460
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
BFD 2.14.90.0.7 20031029 assertion fail elf.c:3460
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
qemu-fast: Not enough room for program headers (allocated 5, need 7)
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: 
final link failed: Bad value
collect2: ld returned 1 exit status
make[1]: *** [qemu-fast] Fehler 1
make[1]: Leaving directory `/home/gebner/data/tmp/qemu/i386'
make: *** [all] Fehler 1


> What about a some better howto about qemu-fast (how to set up, etc.)
> and: does the kernel-configuration differ somehow with 2.6.x kernels?
I think you don't have to modify the guest anymore for use with qemu-fast 
(unfortunately I can't test that since I'm unable to compile qemu-fast) since 
the latest improvements ([Qemu-devel] Code Copy / New Linux boot code), which 
allow unmodified guests to be run.

As for the host, you only have to activate Universal TUN/TAP device driver 
support if you want networking support (I still have to get that working 
under my debian vm and my netbsd vm).

	Gabriel (Ebner).

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] qemu-fast - a better howto?
@ 2004-03-02 13:41 Fabrice Bellard
  0 siblings, 0 replies; 3+ messages in thread
From: Fabrice Bellard @ 2004-03-02 13:41 UTC (permalink / raw)
  To: qemu-devel


 > What about a better howto about qemu-fast (how to set up, etc.)

I will update the documentation for the next release. My idea is to 
split it between user documentation and technical documentation.

I will also make a fix for the compilation of qemu-fast for the LDT problem.

The current state of qemu-fast in CVS is that it can only launch patched 
OSes, but at near native speeds (no precise benchmarks yet).

The specific "roadmap" for qemu-fast is:

- native floating point support (qemu-fast still uses full emulation for 
floating point, which is slow).

- faster self modifying code support (qemu-fast is slower than qemu on 
16 bit code which heavily uses self modifying code).

- faster memory mapped device access (qemu-fast is slower than qemu for 
VGA emulation).

- huge memory support (qemu-fast can simulate up to 256 MB of RAM, but 
this limit will be increased to 4 GB, and then 64 GB).

Fabrice.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-03-02 13:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-02 13:41 [Qemu-devel] qemu-fast - a better howto? Fabrice Bellard
  -- strict thread matches above, loose matches on Subject: below --
2004-03-01 17:30 Gabriel Guzmics
2004-03-02  0:17 ` Gabriel Ebner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).