[Qemu-devel] The QEMU Accelerator Module

[Qemu-devel] The QEMU Accelerator Module

[Fabrice Bellard]

Hi,

I just commited the first alpha release of the QEMU Accelerator Module 
(aka KQEMU) in the CVS. It gives better performance for the "x86 on x86" 
case by running most of the application code as is. It works only for a 
Linux x86 host running a 2.4 or 2.6 kernel. Linux 2.4 and 2.6 kernels 
and Windows 2000 have been runnning as guest OSes, but other OSes may 
work as well. As with every alpha kernel driver testing, it is better to 
backup your data before trying it.

KQEMU is _not_ open source as the rest of QEMU. It is a proprietary 
kernel module (read the LICENSE file) and will stay so until a gentle 
company decides to subsidy the QEMU project.

KQEMU usage is optional: you can disable it at compilation or run time, 
so no one is forced to use it.

Fabrice.

Re: [Qemu-devel] The QEMU Accelerator Module

[Grzegorz Kulewski]

Hi,

On Fri, 11 Feb 2005, Fabrice Bellard wrote:
> I just commited the first alpha release of the QEMU Accelerator Module (aka 
> KQEMU) in the CVS. It gives better performance for the "x86 on x86" case by 
> running most of the application code as is. It works only for a Linux x86 
> host running a 2.4 or 2.6 kernel. Linux 2.4 and 2.6 kernels and Windows 2000 
> have been runnning as guest OSes, but other OSes may work as well. As with 
> every alpha kernel driver testing, it is better to backup your data before 
> trying it.
>
> KQEMU is _not_ open source as the rest of QEMU. It is a proprietary kernel 
> module (read the LICENSE file) and will stay so until a gentle company 
> decides to subsidy the QEMU project.

1. How much? Can the money be collected by comunity (like blender)?
2. What if you will quit making qemu?
3. Are you planning to make and support it completly alone?
4. [Technical question.] Does savannah allow for not open source content 
in their CVS?


Thanks for your work,

Grzegorz Kulewski

Re: [Qemu-devel] The QEMU Accelerator Module

[Darryl Dixon]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

Hi Fabrice!

    Congratulations on the release of this very important code, it has
been much anticipated!  :)  A quick question: if the module does not
allow for redistribution, how does this affect the nightly source
tarballs that I am used to grabbing from dad-answers - will these not be
able to contain this module?  CVS access is very difficult for some (me
in particular :) because of fascist firewalls :(

    Also, can I add my $0.02c and say that I too would be happy to
donate a la blender to seeing this module put under the GPL.

Many regards, and thank you for your fantastic work
Darryl Dixon

On Fri, 2005-02-11 at 00:31 +0100, Fabrice Bellard wrote:

> Hi,
> 
> I just commited the first alpha release of the QEMU Accelerator Module 
> (aka KQEMU) in the CVS. It gives better performance for the "x86 on x86" 
> case by running most of the application code as is. It works only for a 
> Linux x86 host running a 2.4 or 2.6 kernel. Linux 2.4 and 2.6 kernels 
> and Windows 2000 have been runnning as guest OSes, but other OSes may 
> work as well. As with every alpha kernel driver testing, it is better to 
> backup your data before trying it.
> 
> KQEMU is _not_ open source as the rest of QEMU. It is a proprietary 
> kernel module (read the LICENSE file) and will stay so until a gentle 
> company decides to subsidy the QEMU project.
> 
> KQEMU usage is optional: you can disable it at compilation or run time, 
> so no one is forced to use it.
> 
> Fabrice.
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>

[-- Attachment #2: Type: text/html, Size: 2805 bytes --]

Re: [Qemu-devel] The QEMU Accelerator Module

[Lennert Buytenhek]

On Fri, Feb 11, 2005 at 12:57:21AM +0100, Grzegorz Kulewski wrote:

> >I just commited the first alpha release of the QEMU Accelerator Module 
> >(aka KQEMU) in the CVS. It gives better performance for the "x86 on x86" 
> >case by running most of the application code as is. It works only for a 
> >Linux x86 host running a 2.4 or 2.6 kernel. Linux 2.4 and 2.6 kernels and 
> >Windows 2000 have been runnning as guest OSes, but other OSes may work as 
> >well. As with every alpha kernel driver testing, it is better to backup 
> >your data before trying it.
> >
> >KQEMU is _not_ open source as the rest of QEMU. It is a proprietary kernel 
> >module (read the LICENSE file) and will stay so until a gentle company 
> >decides to subsidy the QEMU project.
> 
> 1. How much? Can the money be collected by comunity (like blender)?

I'm interested in this as well.  How much would you need?


> 4. [Technical question.] Does savannah allow for not open source content 
> in their CVS?

I don't think so.

	This web site (called Savannah) is a central point for
	development, distribution and maintenance of Free Software
	that runs on free operating systems.


> Thanks for your work,

Same for me here.


--L

Re: [Qemu-devel] The QEMU Accelerator Module

[Hetz Ben Hamo]

Hi,

The snapshots in my web site (dad-answers.com) are grabbed nightly
from the main CVS server at savannah.

In case the code will be needed to remove due to some conflictions in
licensing with the Savannah team, then I'll make sure that the kernel
code will be available at my web site as well.

Thanks,
Hetz


On Fri, 11 Feb 2005 13:38:40 +1300, Darryl Dixon
<esrever_otua@pythonhacker.is-a-geek.net> wrote:
>  Hi Fabrice!
>  
>      Congratulations on the release of this very important code, it has been
> much anticipated!  :)  A quick question: if the module does not allow for
> redistribution, how does this affect the nightly source tarballs that I am
> used to grabbing from dad-answers - will these not be able to contain this
> module?  CVS access is very difficult for some (me in particular :) because
> of fascist firewalls :(
>  
>      Also, can I add my $0.02c and say that I too would be happy to donate a
> la blender to seeing this module put under the GPL.
>  
>  Many regards, and thank you for your fantastic work
>  Darryl Dixon
> 
>  
>  On Fri, 2005-02-11 at 00:31 +0100, Fabrice Bellard wrote: 
>  Hi, I just commited the first alpha release of the QEMU Accelerator Module
> (aka KQEMU) in the CVS. It gives better performance for the "x86 on x86"
> case by running most of the application code as is. It works only for a
> Linux x86 host running a 2.4 or 2.6 kernel. Linux 2.4 and 2.6 kernels and
> Windows 2000 have been runnning as guest OSes, but other OSes may work as
> well. As with every alpha kernel driver testing, it is better to backup your
> data before trying it. KQEMU is _not_ open source as the rest of QEMU. It is
> a proprietary kernel module (read the LICENSE file) and will stay so until a
> gentle company decides to subsidy the QEMU project. KQEMU usage is optional:
> you can disable it at compilation or run time, so no one is forced to use
> it. Fabrice. _______________________________________________ Qemu-devel
> mailing list Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel 
>  -- 
>  Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
>

Re: [Qemu-devel] The QEMU Accelerator Module

[Leigh Dyer]

Fabrice Bellard wrote:
> Hi,
> 
> KQEMU is _not_ open source as the rest of QEMU. It is a proprietary 
> kernel module (read the LICENSE file) and will stay so until a gentle 
> company decides to subsidy the QEMU project.

Thanks, Fabrice, for your amazing work with QEMU. I can certainly 
understand why you've made KQEMU closed for the moment, and I too would 
probably be willing to contribute to a bounty on opening it.

In the meantime, what are the chances of getting KQEMU running on an 
AMD64 kernel? I'm happy to run 32-bit binaries on my 64-bit system, but 
I don't relish the thought of having to use a 32-bit kernel to run 
accelerated QEMU.

Thanks
Leigh

Re: [Qemu-devel] The QEMU Accelerator Module

[Tim]

> 1. How much? Can the money be collected by comunity (like blender)?

I would also contribute, if this were an option to keep the source
completely free (as in freedom).

tim

Re: [Qemu-devel] The QEMU Accelerator Module

[James Mastros]

Fabrice Bellard wrote:
> KQEMU usage is optional: you can disable it at compilation or run time, 
> so no one is forced to use it.
Would it be feasible to isolate the code that is GPL'd vs non-GPL'd, and 
clearly mark what files are non-GPL'd, preferably by putting them in a 
different CVS module, or sepperate subdirectory of the present CVS 
module, and a sepperate tarball in the next released version?

Doing that would make life /vastly/ easier for distributions, OS 
mirrors, and other such people, as well as people, like me, who want not 
to be tainted.

I notice that there already is a kqemu directory extant -- does it 
include all the non-GPL code?

	-=- James Mastros

Re: [Qemu-devel] The QEMU Accelerator Module

[Tom Marble]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

Fabrice Bellard wrote:

> KQEMU is _not_ open source as the rest of QEMU. It is a proprietary
> kernel module (read the LICENSE file) and will stay so until a gentle
> company decides to subsidy the QEMU project.

I'd like to make an appeal that KQEMU be licensed under the GPL.

I'm not going to try to roll out a general FOSS position statement, but
speak from a more practical level:
- This technology is extremely important for faciliting automated
  testing of the full (open) stack (including BIOS, ACPI, storage,
  graphics, OS, swsusp).  And that testing is vital to the continuing quality
  and vibrance of the entire stack.
- non-GPL kernel modules will taint the kernel and completely
  change the trajectory of the technology (it's support, innovation,
  evolution, etc.)
- Clearly Fabrice is (currently) in the comfortable position of
  being the Benevolent Dictator ( http://en.wikipedia.org/wiki/Benevolent_dictator ).
  I'm sure that's a position that could lead to speaking engagements,
  books, consulting and other forms of monetization which
  are quite compatible with the GPL.

Is KQEMU valuable?  Absolutely!  Could it be proprietary?  Of course
(vis VMware).  In this strange calculus of open source, as counterintuitive
as it seems, I'm convinced that it can be even *more* valuable as
GPL technology (to the community) and more valuable to Fabrice
personally.  While there may be many shades of 'open' (e.g. blender)
I'm sure that that community would be much more productive
with a GPL license and consequently would provide much more
enthusiastic support of whatever Fabrice needs.

I'm sure everyone would be willing to help Googlebomb and /.
Qemu, right?  (Or better yet, help make KQEMU *even better*
through many eyes so that it can really reach a new level of success).

Sincerely,

--Tom

P.S. Some press already
  http://slashdot.org/article.pl?sid=04/11/10/1320231&tid=201&tid=190&tid=1
  http://yro.slashdot.org/article.pl?sid=04/10/21/176235&tid=93&tid=158
  http://en.wikipedia.org/wiki/Qemu
  http://freshmeat.net/projects/qemu/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Qemu-devel] The QEMU Accelerator Module

[Karel Gardas]

Tom,

On Thu, 10 Feb 2005, Tom Marble wrote:

> Fabrice Bellard wrote:
>
> > KQEMU is _not_ open source as the rest of QEMU. It is a proprietary
> > kernel module (read the LICENSE file) and will stay so until a gentle
> > company decides to subsidy the QEMU project.
>
> I'd like to make an appeal that KQEMU be licensed under the GPL.
>
> I'm not going to try to roll out a general FOSS position statement, but
> speak from a more practical level:
> - This technology is extremely important for faciliting automated
>   testing of the full (open) stack (including BIOS, ACPI, storage,
>   graphics, OS, swsusp).  And that testing is vital to the continuing quality
>   and vibrance of the entire stack.
> - non-GPL kernel modules will taint the kernel and completely
>   change the trajectory of the technology (it's support, innovation,
>   evolution, etc.)
> - Clearly Fabrice is (currently) in the comfortable position of
>   being the Benevolent Dictator ( http://en.wikipedia.org/wiki/Benevolent_dictator ).
>   I'm sure that's a position that could lead to speaking engagements,
>   books, consulting and other forms of monetization which
>   are quite compatible with the GPL.
>
> Is KQEMU valuable?  Absolutely!  Could it be proprietary?  Of course
> (vis VMware).  In this strange calculus of open source, as counterintuitive
> as it seems, I'm convinced that it can be even *more* valuable as
> GPL technology (to the community) and more valuable to Fabrice
> personally.  While there may be many shades of 'open' (e.g. blender)
> I'm sure that that community would be much more productive
> with a GPL license and consequently would provide much more
> enthusiastic support of whatever Fabrice needs.
>
> I'm sure everyone would be willing to help Googlebomb and /.
> Qemu, right?  (Or better yet, help make KQEMU *even better*
> through many eyes so that it can really reach a new level of success).

I think that you makes your appeal on the wrong side. Please read
Fabrice's note above. You should rather contact your Linux distribution
vendor and try to convience it to sponsor kqemu development and switch to
GPL. You can also contact some other linux friendly companies like IBM/HP
to do the same.

I'm afraid you are not right with your preassure to how much this
technology is important. No, it is not important for testing of
BIOS/ACPI/kernel etc. It's just very important for end user because of
possible (as I hope) performance benefit.

Please consider how Fabrice is really nice to Qemu community. He makes the
core of kqemu free (as a beer) and just limits its _redistribution_. I can
imagine, he also could make it completely proprietary and force you to
spend $$$ for its download. So if I understand this message right, it is
just to Linux commercial distributors: `Would you like to distribute
_fast_ Qemu? OK, so please pay for its development'. Please consider that
the same these vendors do for many other applications, even core like
kernel, gcc, binutils, wine/crossover (which is even wholy proprietary)
and such. Linux vendors seems to pay for every important technology which
makes them more competitive in linux distributions market, so why also
don't pay for Qemu a bit?

Once again I would like to thank Fabrice for making kqemu enough free that
Qemu user community can benefit from it and provide some bugreports, which
hopefully will be also benefit to kqemu itself. I hope that members of
Qemu community will understand this Fabrice's step and will support him in
finding appropriate company willing to pay for (K)Qemu's development.

Cheers,
Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: [Qemu-devel] The QEMU Accelerator Module

[Lionel Ulmer]

On Fri, Feb 11, 2005 at 10:23:59AM +0100, Karel Gardas wrote:
> (...) Please consider that
> the same these vendors do for many other applications, even core like
> kernel, gcc, binutils, wine/crossover (which is even wholy proprietary)
> and such.

I do not see what Wine (fully LGPL'ed and without any - that I know of -
Linux distribution sponsors) and CrossOver (which is not wholly proprietary
as 95 % of the code is pure LGPL'ed Wine code and that, except for some
packagings deals, is only paid for by CodeWeavers itself) does in this list
:-)

    Lionel (who can't wait to go back home to test QEMU / KQEMU :-) )

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] The QEMU Accelerator Module

[Johannes Schindelin]

Hi,

On Thu, 10 Feb 2005, Tom Marble wrote:

> I'd like to make an appeal that KQEMU be licensed under the GPL.

Me, too. But not without compensation for the wonderful work of Fabrice!
It is just plain wrong to ask anybody to work for free. I personally know
programmers who get paid a lot of money, but their work is just a POC.

Fabrice, to the contrary, came up with a very usable *and* elegant
program. Everybody who benefitted from his work should be content with
what license he chose IMHO (the "Put up or shut up" principle).

Having said that, I think that it might be a good idea if the readers of
this list decide on a target company, and hit them with polite requests.

Target companies I suggest:

	- IBM (they should be very much interested in using QEmu on their
		new Cell processors; imagine that: a processor which is
		10x faster than Pentium natively, with a great emulator
		like QEmu => still faster than Pentium!)
	- Novell (just because they do great work, and are great sponsors)
	- RedHat (just because they are the best known Linux company)

Of course, sponsorship always has its downsides, too, but I think that
Fabrice has well earned some big bucks for this great project!

Just them noo 2 Eurocents of yours truly,
Dscho

Re: [Qemu-devel] The QEMU Accelerator Module

[Karel Gardas]

On Fri, 11 Feb 2005, Lionel Ulmer wrote:

> On Fri, Feb 11, 2005 at 10:23:59AM +0100, Karel Gardas wrote:
> > (...) Please consider that
> > the same these vendors do for many other applications, even core like
> > kernel, gcc, binutils, wine/crossover (which is even wholy proprietary)
> > and such.
>
> I do not see what Wine (fully LGPL'ed and without any - that I know of -
> Linux distribution sponsors) and CrossOver (which is not wholly proprietary
> as 95 % of the code is pure LGPL'ed Wine code and that, except for some
> packagings deals, is only paid for by CodeWeavers itself) does in this list
> :-)

It was my impression that if you like to have SuSE distro with CrossOver,
you have to buy some kind of SuSE product/cd/dvd instead of just do plain
ftp install. From this I've wrongly assumed that CrossOver is proprietary,
sorry for that mistake and thanks for the clarification.

Anyway, if it is (L)GPL, then even better, since then you are in the same
situation like with kernel/gcc/binutils which are also sponsored by
someone/someparty and which approach probably Fabrice would like to apply
to Qemu too. :-)

Thanks,
Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: [Qemu-devel] The QEMU Accelerator Module

[Jens Arm]

> Target companies I suggest:
> 
> 	- IBM (they should be very much interested in using QEmu on their
> 		new Cell processors; imagine that: a processor which is
> 		10x faster than Pentium natively, with a great emulator
> 		like QEmu => still faster than Pentium!)
> 	- Novell (just because they do great work, and are great sponsors)
> 	- RedHat (just because they are the best known Linux company)

or MDK (Mandrake) they sponsored that bochs get under GPL :)

Jens

Re: [Qemu-devel] The QEMU Accelerator Module

[Lionel Ulmer]

On Fri, Feb 11, 2005 at 01:05:12PM +0100, Karel Gardas wrote:
> It was my impression that if you like to have SuSE distro with CrossOver,
> you have to buy some kind of SuSE product/cd/dvd instead of just do plain
> ftp install. From this I've wrongly assumed that CrossOver is proprietary,
> sorry for that mistake and thanks for the clarification.

Well, this is the 'packaging' deal I was talking about (some SuSE
distributions came with CrossOver installed natively).

As for the proprietariness (?) of CrossOver, the 'core' of it (i.e. Wine) is
a modified version of Wine (so you can get the source for it as it is
LGPL'ed) but all the 'glue' around it (configuration file creation, pretty
UI to install application, desktop integration, ...) *is* closed source.

I was just reacting to your 'wholly' in your sentence as it's only 'partly'
closed source (a bit like QMEU actually :-) ).

And as they actually sell CrossOver (plus support / porting contracts) I did
not see this as 'sponsoring' (although for a Wine user / developper like me,
it looks like it as a LOT of patches to the Wine tree come from their
employees).

     Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] The QEMU Accelerator Module

[Grzegorz Kulewski]

Hi all,

On Fri, 11 Feb 2005, Karel Gardas wrote:
> On Thu, 10 Feb 2005, Tom Marble wrote:
>> Fabrice Bellard wrote:
>>> KQEMU is _not_ open source as the rest of QEMU. It is a proprietary
>>> kernel module (read the LICENSE file) and will stay so until a gentle
>>> company decides to subsidy the QEMU project.
>>
>> I'd like to make an appeal that KQEMU be licensed under the GPL.

I hope it will happen soon.


>> I'm not going to try to roll out a general FOSS position statement, but
>> speak from a more practical level:
>> - This technology is extremely important for faciliting automated
>>   testing of the full (open) stack (including BIOS, ACPI, storage,
>>   graphics, OS, swsusp).  And that testing is vital to the continuing quality
>>   and vibrance of the entire stack.

Ok, but it does not stop you from testing. Look at the binary-only part 
size and its interface in .c and .h files. If I understand it correclty 
Fabrice (as usual) done things in extremely right way. The proprietary 
module is _only_ the accelerator. All emulation is done in userspace. Both 
with and without kernel module you get the same qemu (modulo 
userspace-only CPU implementation bugs on unpriviledged instructions if 
there are any left). Only some virtualization is done in kernel. So every 
IO device is exactly the same in both versions of qemu.


>> - non-GPL kernel modules will taint the kernel and completely
>>   change the trajectory of the technology (it's support, innovation,
>>   evolution, etc.)

I think that you are not 100% right. I think that adding non-GPL module to 
the kernel is the (nearly only) problem of this aproach because you will 
loss support from LKML and Linux Community. You will need to reproduce all 
problems on vanilla kernel. (It is not clear if even with GPL licence 
kernel developers will want to support kqemu enabled kernels but the 
module is so small and probably so unintrusive that maybe in could be 
merged into -mm very fast or at least be considered as not-the-cause of 
your issues.)

But saying that it will "change the trajectory of the technology" is I 
think a little too much. Ok, you will not be able to hack on the module 
itself but (if I understand it correctly) Fabrice did everything to place 
as little as possible amount of code in it. After several trivial bugfixes 
of its child age it will probably be left untouched. So you can change 
nearly everything in qemu if you like. It is not 100% freedom but say 
99.999%... :-)

Besides, maybe I am not right, but I do not think that more than 1 or 2 
developers of qemu will want to hack on its kernel module. I do not even 
think it will be good. It should remain as small and simple as possible.


>> Is KQEMU valuable?  Absolutely!  Could it be proprietary?  Of course
>> (vis VMware).

There is _big_ difference. In VMware you can change nothing. Not even add 
new device.


>> In this strange calculus of open source, as counterintuitive
>> as it seems, I'm convinced that it can be even *more* valuable as
>> GPL technology (to the community) and more valuable to Fabrice
>> personally.  While there may be many shades of 'open' (e.g. blender)
>> I'm sure that that community would be much more productive
>> with a GPL license and consequently would provide much more
>> enthusiastic support of whatever Fabrice needs.

But I do not see any milionaire on this list? I am wrong?


>> I'm sure everyone would be willing to help Googlebomb and /.
>> Qemu, right?  (Or better yet, help make KQEMU *even better*
>> through many eyes so that it can really reach a new level of success).
>
> I think that you makes your appeal on the wrong side. Please read
> Fabrice's note above. You should rather contact your Linux distribution
> vendor and try to convience it to sponsor kqemu development and switch to
> GPL. You can also contact some other linux friendly companies like IBM/HP
> to do the same.

Exactly. Question if Fabrice will want gigant to support qemu or rather 
several (possibly) smaller companies? (IIRC author of plex86 was fired 
from Mandrake because of some reduction so maybe several companies would 
be better?)


> I'm afraid you are not right with your preassure to how much this
> technology is important. No, it is not important for testing of
> BIOS/ACPI/kernel etc. It's just very important for end user because of
> possible (as I hope) performance benefit.

And BIOS and ACPI and other IO and even priviledged instructions are done 
in userspace in open source code (or I am completly wrong...)

And if you are really briliant programmer you can write that 36k of code 
yourself. The only thing that stops me from (trying) doing so is that 
it would be not fair to Fabrice. Maybe I am too self-confident but it 
really should not be that hard to do if you know kernel programming a 
little (and assembler of course) or have somebody to anwser your 
questions. This is maybe good exercise to everybody: write your own and 
sent it to Fabrice... ;-)  Of course any form of reverse engineering is 
considered cheating and does not produce the main good: learning how to 
make exciting things in kernelspace.


> Once again I would like to thank Fabrice for making kqemu enough free that
> Qemu user community can benefit from it and provide some bugreports, which
> hopefully will be also benefit to kqemu itself. I hope that members of
> Qemu community will understand this Fabrice's step and will support him in
> finding appropriate company willing to pay for (K)Qemu's development.

Me too. :-)


Thanks Fabrice.

Grzegorz Kulewski

Re: [Qemu-devel] The QEMU Accelerator Module

[Derek Fawcus]

Well,
  rather than whinging because Fabrice has not chosen to distribute his
work under your preferred licence.  People could simply reimplement it.

Mind - this involves effort on their behalf,  and some thinking.  So it's
certainly easier to moan.  However I suggest that such moaning is simply
a waste of time and effort.

Now I don't know how Fabrice has done the kqemu module,  but the obvious
approach that springs to mind is simply moving the qemu-fast processing
into the kernel with checks for the address boundary.  So if I was to
attempt to reimplement it,  my starting point would be to approach it
in that fashion.

Namely placing a version of cpu_exec() and/or main_loop() into the kernel
together with the use of the USE_CODE_COPY facility and some bounds checks
such that if the machine being emulated attempted to have accessable memory
above 0xc0000000 it would fall back to the user-space SOFT_MMU emulation.
One could then manipulate the process space such that while the kernel
module was running user space code,  it's process address space (< 0xc0000000)
reflected the emulated machine space.

However,  I've got other things to do,  so the above is not a priority,
and I'm quite happy to use Fabrice's module.  Mind - I need to update
to a more recent version of the code,  my current work is in a version
dating back to ~ September / October last year.

DF

Re: [Qemu-devel] The QEMU Accelerator Module

[Jim C. Brown]

On Fri, Feb 11, 2005 at 04:09:10PM +0000, Derek Fawcus wrote:
> Well,
>   rather than whinging because Fabrice has not chosen to distribute his
> work under your preferred licence.  People could simply reimplement it.

Or do as I am, and figure out how to mix plex86 with the open source part.

Or even better, dig deep in your pockets and sponser Fabrice to completely
open it up.

> 
> Mind - this involves effort on their behalf,  and some thinking.  So it's
> certainly easier to moan.  However I suggest that such moaning is simply
> a waste of time and effort.
> 
> Now I don't know how Fabrice has done the kqemu module,  but the obvious
> approach that springs to mind is simply moving the qemu-fast processing
> into the kernel with checks for the address boundary.  So if I was to
> attempt to reimplement it,  my starting point would be to approach it
> in that fashion.
> 
> Namely placing a version of cpu_exec() and/or main_loop() into the kernel
> together with the use of the USE_CODE_COPY facility and some bounds checks
> such that if the machine being emulated attempted to have accessable memory
> above 0xc0000000 it would fall back to the user-space SOFT_MMU emulation.
> One could then manipulate the process space such that while the kernel
> module was running user space code,  it's process address space (< 0xc0000000)
> reflected the emulated machine space.

That wouldn't be complete, as kqemu uses virtalization as well. Also, it seems
that a lot of the kernel MMU support is in the open source code. Only
kqemu_delete, kqemu_exec, kqemu_get_cpu_state, and kqemu_init need to be
reimplemented.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] The QEMU Accelerator Module

[Fabrice Bellard]

Grzegorz Kulewski wrote:

> 4. [Technical question.] Does savannah allow for not open source content 
> in their CVS?

Sorry I made a mistake here. I am removing the module from the CVS and I 
am putting in the download area of the QEMU web site.

Fabrice.

Re: [Qemu-devel] The QEMU Accelerator Module

[Fabrice Bellard]

Hi,

I just removed the QEMU Accelerator Module (aka KQEMU) from the QEMU CVS 
repository. You can now download it from the QEMU web site 
(http://bellard.org/qemu). QEMU and KQEMU are two different projects 
with different licenses - I hope that it is clearer now.

Fabrice.

Re: [Qemu-devel] The QEMU Accelerator Module

[Bob Barry]

Fabrice -

On Sat, 12 Feb 2005 15:10 you wrote:
> I am putting [the module] in the download area of the QEMU web site.

I could not find it there.  Could you please give a url for it?

Thanks,

Bob Barry

Re: [Qemu-devel] The QEMU Accelerator Module

[Hetz Ben Hamo]

Here: http://fabrice.bellard.free.fr/qemu/download.html

Thanks,
Hetz

On Sat, 12 Feb 2005 17:55:40 +0200, Bob Barry <bobb@absamail.co.za> wrote:
> Fabrice -
> 
> On Sat, 12 Feb 2005 15:10 you wrote:
> > I am putting [the module] in the download area of the QEMU web site.
> 
> I could not find it there.  Could you please give a url for it?
> 
> Thanks,
> 
> Bob Barry
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] The QEMU Accelerator Module

[Panagiotis Issaris]

Bob Barry wrote:

>Fabrice -
>
>On Sat, 12 Feb 2005 15:10 you wrote:
>  
>
>>I am putting [the module] in the download area of the QEMU web site.
>>    
>>
>
>I could not find it there.  Could you please give a url for it?
>  
>
http://fabrice.bellard.free.fr/qemu/download.html

Or a direct link to the tarball:
http://fabrice.bellard.free.fr/qemu/kqemu-0.6.2.tar.gz

With friendly regards,
Takis

-- 
------------------------------------------------------------------------
Panagiotis Issaris
Katholieke Universiteit Leuven
Division Production Engineering,
Machine Design and Automation
Celestijnenlaan 300B              panagiotis.issaris@mech.kuleuven.ac.be
B-3001 Leuven Belgium                 http://www.mech.kuleuven.ac.be/pma
------------------------------------------------------------------------

Re: [Qemu-devel] The QEMU Accelerator Module

[Felipe Sanchez]

On Fri, 11 Feb 2005, Fabrice Bellard wrote:

> KQEMU is _not_ open source as the rest of QEMU. It is a proprietary
> kernel module (read the LICENSE file) and will stay so until a gentle
> company decides to subsidy the QEMU project.

OK, so how much would a "gentle subsidy" be?

My company (like many others) is starting to use QEMU as a part (value add
in some cases, core in others) of some products. Although not required
too, I've personally taken interest in the QEMU project, contributed small
patches and intend to contribute a lot more once I can fully grasp QEMU's
code. That's the spirit of free software I think. We use your project and
we contribute our code and testing to it because it's in everyone's
interest to do so.

I understand Fabrice's new position on KQEMU (Specially after reading
Natalia's insightful comment). So we (my company) would really like to
help. If coding/testing is not enough that's ok. However we are not a big
operation (I'd say we are a rather small one) so we have not much buck to
spare in subsidizing a project like big fish like Novell or IBM would. So
how about setting up a fund, or a community raising effort or something so
all the so-far happy QEMU users and companies can help Fabrice continue to
develop this project?

It has been seen before. Community fund rasing efforts are often
succesful. All we need is a goal (Hence the subject of this e-mail). How
much is it? Maybe even a Slashdot front page story would be in order,
don't you think so?  ;-)


Felipe.