* [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).