[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: RFC for new features

From: Emmanuel Charpentier
Subject: [Qemu-devel] Re: RFC for new features
Date: Fri, 09 Jul 2004 22:27:05 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040704 Debian/1.7-4

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.

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

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]