Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Fabrice Bellard <fabrice@bellard.org>]

Grzegorz Kulewski wrote:
> Hi,
> 
> On Thu, 17 Feb 2005, Herbert Poetzl wrote:
> 
>> On Sat, Feb 12, 2005 at 11:41:55PM +0100, Grzegorz Kulewski wrote:
>>
>>> Hi,
>>>
>>> On Sat, 12 Feb 2005, Jean-Michel POURE wrote:
>>>
>>>> Following Fabrice decision to transform QEMU into a proprietary closed
>>>> solution
>>>
>>>
>>> No, Fabrice did not transform QEMU into anything. He simply added 
>>> another
>>> optional module than can make QEMU faster and more bug-free. You can 
>>> still
>>> use QEMU without the accelerator and be perfectly happy with it. Also 
>>> any
>>> further development in area of IO, devices and so on will make both
>>> versions better. KQEMU is only very small accelerator.
>>
>>
>> well, unfortunately together with the following mail ...
>>
>> | From: Fabrice Bellard <fabrice@bellard.org>
>> | To: qemu-devel@nongnu.org
>> | Date: Sat, 29 Jan 2005 22:48:24 +0100
>> |
>> | Hi,
>> |
>> | I plan to remove the 'qemu-fast' target in the next release of QEMU. It
>> | is too painful to maintain, difficult to port and it needs a patched
>> | guest OS to work correctly.
>> |
>> | This target is replaced by the standard QEMU with soft mmu support. The
>> | QEMU Kernel Acceleration Layer which will be unveiled very soon will
>> | give much more performance while working with unpatched guest OSes.
>> |
>> | Fabrice.
>>
>> the future looks more like this:
>>
>> - you want the same performance or better as before?
>>   then you have to use 'my' proprietary kernel module
>>   which isn't even open source (so that somebody
>>   could verify that it isn't that evil ...)
>>
>> - of course, you can use the slow version and
>>   contribute to the development of the commercial?
>>   version ...
> 
> 
> Well
> 
> 1. qemu-fast is still there but disabled by default,
> 2. qemu-fast used patched kernel and was very limited and probably buggy,
> 3. you can use UML or plex86(?) for the same (== running Linux under 
> Linux),

My decision to disable qemu-fast is not because I fear that there is 
some kind of concurrence with kqemu. I wanted to do that since a long 
time. Here are a few reasons:

1) I feel that running patched OSes is not a good target for QEMU. The 
strength of QEMU is to run unpatched OSes. Otherwise there are many 
other good solutions (Xen, UML, new plex86). qemu-fast was just a hack 
before I got convinced to implemented the soft mmu.

2) qemu-fast is difficult to maintain - it uses too many hacks to have 
full control over the address space.

3) qemu-fast is not safe (no address space protection).

4) qemu-fast performance is limited by the mmap() performance, 
especially in case of frequent process switches (try a kernel 
compilation !).

qemu-fast can have some future, but it involves a lot of work and I 
don't have the time to do it yet. Here are a few ideas:

- Use a separate process to run the translator so that the UI can run in 
its own address space with dynamic libraries.

- Use segments limits to protect the translator code

- Use kqemu to execute the translator in a separate address space.

However, it is better to spend time on a better soft mmu (I plan to 
merge the last published patches for that) and on a better kqemu (when 
it will be GPLed).

Fabrice.