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

[Fabrice Bellard]

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 <address@hidden>
> > | To: address@hidden
> > | 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.