Re: [Qemu-devel] Re: RFC for new features

[Antony T Curtis]

On Fri, 2004-07-09 at 21:27, Emmanuel Charpentier wrote:
> Fabrice Bellard wrote:
> 
> [ that he wants our whishlists before porting the SDL version to other 
> platforms. ]
> 
> Well, I have some wishes, but I'm not sure they fit well in your current 
> worplans. Please feel free to discard them :
> 
> 1) There are still some CPU emulation issues ; I can't diagnose them but I 
> can prove that they exist :
>       After Win2k installation (whatever version), I have been unable to 
> install 
> Mozilla 1.6. I have been able to install Mozilla 1.7, though. Windows being 
> .. well, Windows, I've been unable to locate error logs. Go figure ...
>       It tool me 4 trials to find a Win2k version that would allow for the 
> installation of Office 2000. I tried to install Office 97 twice, with no 
> luck. I didn't retry with the "correct" installation of Win2k.
>       The SP4 patch doesn't install (error a short while after unpacking)
>       The "disk full" issue while installing Win2k still happens every time.
> 
> None of this happens using the very same files/disks while installing on 
> real hardware.

Yes - I think that there are instances where the simulation is wrong...
OS/2 Warp 3 seems to suffer from GPFs when running applications
consistantly and repeatably.

> 2) There are device emulation issues :
>       The current cirrusvga is a vast improvement over the previous bochs 
> device. However, pushing available memory to more than 4 Mb wold allow for 
> better resolutions : 1024x768x16 is a bit limiting in some uses.
>       There are still serious issues with audio emulation. The current 
> SB16/AXE 
> device can do simple things (playing the "opening" .wav file, etc ...), but 
> trying to install Dragon voice recognition still fails very early (at the 
> first sound that the installer tries to play), and crashes the whole 
> emulation (the graphics window diseappear, and you're left with no mouse).

Well - the CL-GD544X chips can only handle 4MB of memory, maximum. For
larger framebuffers, we would have to emulate a different video chip -
If we wish to stick to Cirrus Logic, The Laguna CL-GD546x chips can
address up to 16MB I think.... Of course, there are many other chips - I
think perhaps the Tseng Labs ET6000 may be simple enough to simulate and
would support a larger framebuffer.

> 3) I still think that a virtualizer based on QEMU, while quite a bit more 
> limited in scope than QEMU itself, would be extremely useful : letting 
> user-level code not touching hardware run native and trapping anything 
> related to I/O, memory-mapped I/O or changing protection level (allowing to 
> run *that* on the emulated CPU) would allow for a nice acceleration. This 
> would be a boon for all the people using QEMU to run hardware available for 
> their CPU but not their platform (think Windows user running Linux/FreeBSD 
> software and vice-versa), which may well be a majority among qemu users.

Hmm... If a virtualizer is what is wanted, there are several options
already available... "Xen" is supposedly very good.
I think QEmu's strength is that it is not a virtualizer - it is a system
simulator.

Perhaps work can be done to get better performance when simulating the a
similar system to the host... but perhaps there would be more real
benefit in attemting to make the translator optimise the code it
generates... LUA has already been mentioned as a possible alternative
code generator.

> None of this is absolutely critical, and QEMU is already *extremely* 
> useable (and useful ! ) as it is. The most critical are probably the CPU 
> emulation issues, the least the virtualizer.
> 
> Hope this helps,
> 
>                                       Emmanuel Charpentier
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>  FLAGS (\Seen))
-- 
Antony T Curtis <address@hidden>