[Qemu-devel] Qemu - where will it go?

[Qemu-devel] Qemu - where will it go?

[Juergen Pfennig]

Hello dear readers,

as I found out qemu is quite stable and has acceptable performance. Using it you
could freeze legacy applications using a legacy OS like win 2003 or win XP. I am
talking of periods from 5 to 20 years! In a commercial environment it happens 
frequently that you would like to access old data but cannot do so because the
hardware is gone or the old software does not work with the current OS.

Commercial vm solutions cannot really do that - as they are not open source you
only move the dependecies from hardware to a software vendor. Both usually
become unavailable over time. Hardware vitualization (xen, vanderpool) is also
not an ideal long-term solution, you become again hard-ware depending...

This is what makes qemu so interesting for industry and business.

But a lot of work would have to be done. The next steps of development would
probably include:

- run qemu as a service (on Windows or on Linux using xinetd)
- make rdp (Win Terminal Server) work when qemu started via
  xinetd
- improve disk image format, better snapshot handling
- make a plugin architecture for the host side device implementation
- allow 'remote' host side devices (sound, usb, serial ...)
- define a protocol to use qemu over a network (should multiplex
  video, sound, usb, serial and so on).

So you see: in a commercial  and or industrial application one would like to run 
the qemus on a server. At least the MS remote desktop protocol should work
well. A qemu specific client would be nicer. 

Please do not try to make the current qemu program a better GUI application -
do it the other way: move SDL out of qemu and write an extra client app!

I did not find any information concerning the plans that the maintainers of
qemu have.

- currently it is simple and easy to understand. It has supringly few lines
  of code.
- the concept would allow for better performance (dynamic code generation
  could use optimization to eliminate inter module function calls, see some
  of the java jit propaganda).
- currently the code translation cache is a problem for old-style windows
  apps. Word and friends run slowly as the cache runs full and gets 
  rebuilt too often. The current implementation may lead to degeneration,
  e.g. a very low cache hit ratio.
- obviously a generational code translation cache should be used, e.g.
  frequently executed code would not be lost but would be promoted to
  the next generation cache. See the .net gc propaganda.
- Finally one could take some ReactOS drivers to get better perfor-
  mace by not going through hw emulation but by making the ReatOS
  drivers stubs that can call native implementations on the host side.

Unfortunately implementing the things that I was talking about would blow
up the size of the code base dramatically. Qemu would never again be
small, pretty and easy to understand. Where do you want to go?

Yours Jürgen

Re: [Qemu-devel] Qemu - where will it go?

[Thomas Steffen]

Hi Juergen!

On 1/14/06, Juergen Pfennig <info@j-pfennig.de> wrote:
> as I found out qemu is quite stable and has acceptable performance. Using it you
> could freeze legacy applications using a legacy OS like win 2003 or win XP. I am
> talking of periods from 5 to 20 years!

Yes, that is a good idea. Having a defined VM is probably the most
stable computing environment you can get. If it is a well used one,
all the better. I have seen research projects that would build a
custom VM in Java (!), and then program a PDF viewer for this VM.
Which is of course mostly useless, compared to all the great things
you can do with Qemu, and without Java.

> But a lot of work would have to be done. The next steps of development would
> probably include:
>
> - run qemu as a service (on Windows or on Linux using xinetd)
> - make rdp (Win Terminal Server) work when qemu started via
>   xinetd
> - improve disk image format, better snapshot handling
> - make a plugin architecture for the host side device implementation
> - allow 'remote' host side devices (sound, usb, serial ...)
> - define a protocol to use qemu over a network (should multiplex
>   video, sound, usb, serial and so on).

While I agree that all these ideas are nice, I am not sure they are
essential for a "legacy" VM. I think there are two main
considerations:

1. Reduce your dependencies to things that you expect to be around in
10 years time.

2. Keep the data format stable.

For 1. it would be nice to use only standard C (POSIX ???), but due to
the way Qemu works, it needs to know about the link format used on
your platform. ELF seems to be a reasonable stable format, but we have
seen several transitions on Linux (glibc4, 5 and now 6), so there
could be more (incompatible) changes in the future.

2. is a question of development priorities. Assuming that Qemu 0.8
might not compile in 10 years time any more, Qemu 4.9 (or whatever we
have then) should be able to read Qemu 0.8 images. Maybe this is what
you mean by "improve disk image format". But since Qemu does supports
plain images, I do not see how you could make the format more stable
:-)

> So you see: in a commercial  and or industrial application one would like to run
> the qemus on a server. At least the MS remote desktop protocol should work
> well. A qemu specific client would be nicer.

Actually X11 should work nicely, and it is much more open than RDP.
VNC also seems to be stable, but it is a lot less used.

> Unfortunately implementing the things that I was talking about would blow
> up the size of the code base dramatically. Qemu would never again be
> small, pretty and easy to understand. Where do you want to go?

I am not a developer, but I would prefer it small and pretty :-). If
it is not fast enough, wait 6 month and buy a faster CPU... But that
is just my personal view.

Thomas

Re: [Qemu-devel] Qemu - where will it go?

[Oliver Gerlich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

that's an interesting topic you bring up there :D

It looks like there are many different groups which all have quite
different uses of qemu on their mind... Jürgen, you think about a
_really_ stable "hardware" platform; other people think about a honeypot
framework; even other people want to have lots of different system
architectures for software development and testing; I myself just want a
way to have a Windows available on my Linux PC, for gaming and running
Windows apps. Not to mention the various toy-like uses, like the Linux
screensaver. And if I got that correctly, one of the original uses of
qemu was to run wine on PPC - ironically, this is probably not such an
issue now, with Apple switching to x86 :)

So, to me it seems like the many different uses of qemu indeed need a
very different qemu each; and though I'm not a qemu developer at all
(and hence can't "demand" any specific direction of development), I'd be
glad if qemu wouldn't just go into one direction.
Maybe it is indeed about time to think about the "main uses" that qemu
should satisfy. For me, that would be the "Windows-sandbox on my Desktop
Linux": with a nice GUI, an assistant to help with the creation of a new
image, with some guest-side tools for more convenience, with not too
slow graphics, and without big ties to the host system.

Jürgen has stated his desired functionality already. What other "main
uses" are there? (Asked in the hope of further sparking the discussion ;)


To summarize what in my opinion are the most important advantages of qemu:

Over eg. VMware and VPC, it has these advantages:
- -small
- -easy to install; VMware requires a kernel module from the start, and
requires running of an installation script (*yuck* and that in times of
RPM and APT).
- -Open Source (= possibility to meddle with it by myself; and no
dependency on a self-centered, not-to-be-trusted company)

Over Wine, qemu has the advantage that it runs guest apps without any
worrying whether the emulation is "complete enough" for that app.
Over Xen and UML, it has the advantage that it runs Windows, even
without special hardware.
Over Bochs, it has the advantage that qemu runs fast yet still reliable
enough.

What other product did I miss that might compete with qemu? What
advantages of qemu did I miss?

Thanks in advance for your replies,
Oliver


Juergen Pfennig schrieb:
> Hello dear readers,
> 
> as I found out qemu is quite stable and has acceptable performance. Using it you
> could freeze legacy applications using a legacy OS like win 2003 or win XP. I am
> talking of periods from 5 to 20 years! In a commercial environment it happens 
> frequently that you would like to access old data but cannot do so because the
> hardware is gone or the old software does not work with the current OS.
> 
> Commercial vm solutions cannot really do that - as they are not open source you
> only move the dependecies from hardware to a software vendor. Both usually
> become unavailable over time. Hardware vitualization (xen, vanderpool) is also
> not an ideal long-term solution, you become again hard-ware depending...
> 
> This is what makes qemu so interesting for industry and business.
> 
> But a lot of work would have to be done. The next steps of development would
> probably include:
> 
> - run qemu as a service (on Windows or on Linux using xinetd)
> - make rdp (Win Terminal Server) work when qemu started via
>   xinetd
> - improve disk image format, better snapshot handling
> - make a plugin architecture for the host side device implementation
> - allow 'remote' host side devices (sound, usb, serial ...)
> - define a protocol to use qemu over a network (should multiplex
>   video, sound, usb, serial and so on).
> 
> So you see: in a commercial  and or industrial application one would like to run 
> the qemus on a server. At least the MS remote desktop protocol should work
> well. A qemu specific client would be nicer. 
> 
> Please do not try to make the current qemu program a better GUI application -
> do it the other way: move SDL out of qemu and write an extra client app!
> 
> I did not find any information concerning the plans that the maintainers of
> qemu have.
> 
> - currently it is simple and easy to understand. It has supringly few lines
>   of code.
> - the concept would allow for better performance (dynamic code generation
>   could use optimization to eliminate inter module function calls, see some
>   of the java jit propaganda).
> - currently the code translation cache is a problem for old-style windows
>   apps. Word and friends run slowly as the cache runs full and gets 
>   rebuilt too often. The current implementation may lead to degeneration,
>   e.g. a very low cache hit ratio.
> - obviously a generational code translation cache should be used, e.g.
>   frequently executed code would not be lost but would be promoted to
>   the next generation cache. See the .net gc propaganda.
> - Finally one could take some ReactOS drivers to get better perfor-
>   mace by not going through hw emulation but by making the ReatOS
>   drivers stubs that can call native implementations on the host side.
> 
> Unfortunately implementing the things that I was talking about would blow
> up the size of the code base dramatically. Qemu would never again be
> small, pretty and easy to understand. Where do you want to go?
> 
> Yours Jürgen
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDyU7yTFOM6DcNJ6cRAjg2AJ41ExETauoBTmvl+r55OZO4P6kviwCgrVDj
TO8WUc4eRT1El0jFjI9aYvc=
=rYlu
-----END PGP SIGNATURE-----

Re: [Qemu-devel] Qemu - where will it go?

[Wesley Parish]

On Sun, 15 Jan 2006 08:20, Oliver Gerlich wrote:
> Hi,
>
> that's an interesting topic you bring up there :D
>
> It looks like there are many different groups which all have quite
> different uses of qemu on their mind... Jürgen, you think about a
> _really_ stable "hardware" platform; other people think about a honeypot
> framework; even other people want to have lots of different system
> architectures for software development and testing; I myself just want a
> way to have a Windows available on my Linux PC, for gaming and running
> Windows apps. Not to mention the various toy-like uses, like the Linux
> screensaver. And if I got that correctly, one of the original uses of
> qemu was to run wine on PPC - ironically, this is probably not such an
> issue now, with Apple switching to x86 :)
>
> So, to me it seems like the many different uses of qemu indeed need a
> very different qemu each; and though I'm not a qemu developer at all
> (and hence can't "demand" any specific direction of development), I'd be
> glad if qemu wouldn't just go into one direction.
> Maybe it is indeed about time to think about the "main uses" that qemu
> should satisfy. For me, that would be the "Windows-sandbox on my Desktop
> Linux": with a nice GUI, an assistant to help with the creation of a new
> image, with some guest-side tools for more convenience, with not too
> slow graphics, and without big ties to the host system.
>
> Jürgen has stated his desired functionality already. What other "main
> uses" are there? (Asked in the hope of further sparking the discussion ;)

Well, my main interest is in running MS Windows (as many versions as possible) 
on my Linux box for gaming and development purposes - eg, rewriting various 
bits and pieces of DOOM and Quake etc, using MinGW, etc, testing new and 
up-and-coming F/LOS OSes such as ReactOS and Syllable, and suchlike.

Wesley Parish
<Snip>
> >
> > Yours Jürgen
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Clinersterton beademung, with all of love - RIP James Blish
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.

Re: [Qemu-devel] Qemu - where will it go?

[Paul Brook]

> Jürgen has stated his desired functionality already. What other "main
> uses" are there? (Asked in the hope of further sparking the discussion ;)

I use the usermode emulation fairly extensively for cross development/testing.
User emulation has three main advantages for our purposes:

- It's significantly faster than full system emulation, especially when the 
target system would be using an NFSroot.

- It doesn't rely on a target kernel. These frequently have bugs, especially 
on the less popular architectures..

- It's much easier to integrate into test harnesses. With binfmt_misc it's 
mostly transparent. For full system emulation you have to mess about with 
telnet/rsh.

The main downside is that threaded applications don't currently work properly, 
but that's fixable.

Paul

Re: [Qemu-devel] Qemu - where will it go?

[andrzej zaborowski]

Hi,

> - define a protocol to use qemu over a network (should multiplex
>   video, sound, usb, serial and so on).
>
> So you see: in a commercial  and or industrial application one would like to run
> the qemus on a server. At least the MS remote desktop protocol should work
> well. A qemu specific client would be nicer.
>
> Please do not try to make the current qemu program a better GUI application -
> do it the other way: move SDL out of qemu and write an extra client app!
>

I'm not a QEMU developer but I don't think QEMU is seeking commercial
and or industrial popularity (I might be wrong though). Personally I'd
rather be trying to keep it small and do its own task well rather than
reimplement in QEMU parts of other programs' tasks. The universal
rules of writing cross-platform software clearly show that
dependencies on other packages (libraries, utilities) are a good
thing. It's also one of the UNIX traditions to have big tasks divided
into small parts and each of them be carried out by a different tool.
So I think the existing protocols should be used for remote control,
SDL supports several different frontends for audio and video and many
of them already offer full network transparency (X, esound), and for
USB, other, platform-specific mechanisms can be used for remote
devices (like the Linux network block/character devices support).

I agree with your other points.

Regards,
Andrew
--
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

Re: [Qemu-devel] Qemu - where will it go?

[Fabrice Bellard]

Hi,

Using legacy apps is clearly an interesting topic for QEMU. With the 
improved dynamic translator written by Paul Brook (but not merged yet), 
QEMU will be far less dependent of C compiler and porting the dynamic 
translator to a new host will still be simple. Fortunately (or not !), 
it is very likely that the x86 hosts will prevail for many years, so the 
dynamic generation back end won't need much change for some time.

I am currently interested by improving the performance of QEMU for the 
x86 target and host thru the accelerator and better device drivers (non 
blocking I/O patch, network with pcnet and DMA).

I have other topics on my TODO list but with a lower priority:

- better debugging features
- VNC server (merge the VNC patch)
- plugin system to develop new devices and machines without recompiling 
QEMU, config files, single binary for all targets
- GUI

I believe that QEMU can stay "small" while containing all these features.

Fabrice.

Juergen Pfennig wrote:
> Hello dear readers,
> 
> as I found out qemu is quite stable and has acceptable performance. Using it you
> could freeze legacy applications using a legacy OS like win 2003 or win XP. I am
> talking of periods from 5 to 20 years! In a commercial environment it happens 
> frequently that you would like to access old data but cannot do so because the
> hardware is gone or the old software does not work with the current OS.
> 
> Commercial vm solutions cannot really do that - as they are not open source you
> only move the dependecies from hardware to a software vendor. Both usually
> become unavailable over time. Hardware vitualization (xen, vanderpool) is also
> not an ideal long-term solution, you become again hard-ware depending...
> 
> This is what makes qemu so interesting for industry and business.
> 
> But a lot of work would have to be done. The next steps of development would
> probably include:
> 
> - run qemu as a service (on Windows or on Linux using xinetd)
> - make rdp (Win Terminal Server) work when qemu started via
>   xinetd
> - improve disk image format, better snapshot handling
> - make a plugin architecture for the host side device implementation
> - allow 'remote' host side devices (sound, usb, serial ...)
> - define a protocol to use qemu over a network (should multiplex
>   video, sound, usb, serial and so on).
> 
> So you see: in a commercial  and or industrial application one would like to run 
> the qemus on a server. At least the MS remote desktop protocol should work
> well. A qemu specific client would be nicer. 
> 
> Please do not try to make the current qemu program a better GUI application -
> do it the other way: move SDL out of qemu and write an extra client app!
> 
> I did not find any information concerning the plans that the maintainers of
> qemu have.
> 
> - currently it is simple and easy to understand. It has supringly few lines
>   of code.
> - the concept would allow for better performance (dynamic code generation
>   could use optimization to eliminate inter module function calls, see some
>   of the java jit propaganda).
> - currently the code translation cache is a problem for old-style windows
>   apps. Word and friends run slowly as the cache runs full and gets 
>   rebuilt too often. The current implementation may lead to degeneration,
>   e.g. a very low cache hit ratio.
> - obviously a generational code translation cache should be used, e.g.
>   frequently executed code would not be lost but would be promoted to
>   the next generation cache. See the .net gc propaganda.
> - Finally one could take some ReactOS drivers to get better perfor-
>   mace by not going through hw emulation but by making the ReatOS
>   drivers stubs that can call native implementations on the host side.
> 
> Unfortunately implementing the things that I was talking about would blow
> up the size of the code base dramatically. Qemu would never again be
> small, pretty and easy to understand. Where do you want to go?
> 
> Yours Jürgen
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

Re: [Qemu-devel] Qemu - where will it go?

[Johannes Schindelin]

Hi,

On Sun, 15 Jan 2006, Fabrice Bellard wrote:

> Using legacy apps is clearly an interesting topic for QEMU. With the 
> improved dynamic translator written by Paul Brook (but not merged yet), 
> QEMU will be far less dependent of C compiler and porting the dynamic 
> translator to a new host will still be simple.

Just wondering: Deducing from the above, you are willing to merge it... 
You have any plan as to when?

> - VNC server (merge the VNC patch)

The big problem remains: How to keep host and guest cursor in sync.

Note that I am playing around with a half-working patch to add SummaSketch 
(Tablet) emulation, and maybe eventually Wacom (since some Linux distros 
can autodetect it). Maybe even a USB emulation is needed, but I still 
don't know if Windows/Linux auto-select the absolute positioning. If not, 
all this is mute.

Also, the new LibVNCServer -- due this or next week -- should solve the 
jinky mouse problem.

Ciao,
Dscho