[Qemu-devel] merging kqemu into mainline kernel?

[Qemu-devel] merging kqemu into mainline kernel?

[dragoran]

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

Hello,
Is it planned to submit kqemu to lkml for inclusion into the mainline
kernel?
if not why?
if yes any idea when? is it possible to try to get it in 2.6.24 ?

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

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Ricardo Almeida]

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

Hi,
I'm just a user...

Is it planned to submit kqemu to lkml for inclusion into the mainline
> kernel?


Never seen anyone talking about this...

if not why?


Maybe because KVM was included (
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7)


if yes any idea when? is it possible to try to get it in 2.6.24 ?
>

I don't know if Linus would accept it. As I said, KVM was included, although
kqemu as the advantage of working in older hardware (without AMD-V or Intel
equivalent virtualization instructions).
Maybe if it was possible to make merge kqemu into KVM to take the best of
the two... But I don't know anything about KVM nor kqemu code...

Regards,
Ricardo Almeida

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

Re: [Qemu-devel] merging kqemu into mainline kernel?

[dragoran]

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

On 8/4/07, Ricardo Almeida <ric.almeida@gmail.com> wrote:
>
> Hi,
> I'm just a user...
>
> Is it planned to submit kqemu to lkml for inclusion into the mainline
> > kernel?
>
>
> Never seen anyone talking about this...
>
> if not why?
>
>
> Maybe because KVM was included (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7
> )
>

I know that

if yes any idea when? is it possible to try to get it in 2.6.24 ?
> >
>
> I don't know if Linus would accept it. As I said, KVM was included,
> although kqemu as the advantage of working in older hardware (without AMD-V
> or Intel equivalent virtualization instructions).
> Maybe if it was possible to make merge kqemu into KVM to take the best of
> the two... But I don't know anything about KVM nor kqemu code...


thats the reason I  (and many other users) want to see it merged.
for ex. the fedora kernel maintainers don't want to add it until its part of
the upstream kernel.

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

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Bill C. Riemers]

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

You don't need to compile kqemu into the kernel.  When I install dkms-kqemu
from freshrpms, I do NOT rebuild my kernel.  I am fairly certain with
Fedora's new policy for extras, there would not be much of a problem getting
it added to Fedora.  For that matter, it could probably get added into the
new Enterprise Extra's repository as well.  However, someone would need to
volunteer to maintain the package.

Bill


On 8/4/07, dragoran <drago01@gmail.com> wrote:
>
>
>
> On 8/4/07, Ricardo Almeida <ric.almeida@gmail.com> wrote:
> >
> > Hi,
> > I'm just a user...
> >
> > Is it planned to submit kqemu to lkml for inclusion into the mainline
> > > kernel?
> >
> >
> > Never seen anyone talking about this...
> >
> > if not why?
> >
> >
> > Maybe because KVM was included (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7
> > )
> >
>
> I know that
>
> if yes any idea when? is it possible to try to get it in 2.6.24 ?
> > >
> >
> > I don't know if Linus would accept it. As I said, KVM was included,
> > although kqemu as the advantage of working in older hardware (without AMD-V
> > or Intel equivalent virtualization instructions).
> > Maybe if it was possible to make merge kqemu into KVM to take the best
> > of the two... But I don't know anything about KVM nor kqemu code...
>
>
> thats the reason I  (and many other users) want to see it merged.
> for ex. the fedora kernel maintainers don't want to add it until its part
> of the upstream kernel.
>
>
>

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

Re: [Qemu-devel] merging kqemu into mainline kernel?

[dragoran]

Bill C. Riemers wrote:
> You don't need to compile kqemu into the kernel.  When I install 
> dkms-kqemu from freshrpms, I do NOT rebuild my kernel.  I am fairly 
> certain with Fedora's new policy for extras, there would not be much 
> of a problem getting it added to Fedora.  For that matter, it could 
> probably get added into the new Enterprise Extra's repository as 
> well.  However, someone would need to volunteer to maintain the package.
no thats not true fedora want to change the policy about out of tree 
modules the want to drop all kmod-* packages and only allow modules into 
the kernel rpm that are upstream or about to get merged upstream.
anyway why has kqemu to be a out of tree module?

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Paul Brook]

On Thursday 16 August 2007, dragoran wrote:
> Bill C. Riemers wrote:
> > You don't need to compile kqemu into the kernel.  When I install
> > dkms-kqemu from freshrpms, I do NOT rebuild my kernel.  I am fairly
> > certain with Fedora's new policy for extras, there would not be much
> > of a problem getting it added to Fedora.  For that matter, it could
> > probably get added into the new Enterprise Extra's repository as
> > well.  However, someone would need to volunteer to maintain the package.
>
> no thats not true fedora want to change the policy about out of tree
> modules the want to drop all kmod-* packages and only allow modules into
> the kernel rpm that are upstream or about to get merged upstream.
> anyway why has kqemu to be a out of tree module?

Mainly because the kernel already has one perfectly good virtualization 
interface. There's very little motivation to add another incompatible one, 
especially when the implementation is known to be fundamentally flawed, and 
probably insecure.

If you really want to get it merged I suggest modifying kqemu to use the kvm 
interface, augmenting the kvm interface if necessary.

Paul

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Leonardo Reiter]

Are you referring to the API when you say interface, or the
functionality itself?  If the former that's a reasonable argument, but
the latter is not valid since KVM requires a VT or AMD-V-capable
processor, right?  KQEMU does not, and therefore [today] works on a
much larger installed base of hardware.  Unless I am misunderstanding
something?

- Leo Reiter

On 8/16/07, Paul Brook <paul@codesourcery.com> wrote:
> On Thursday 16 August 2007, dragoran wrote:
> > Bill C. Riemers wrote:
> > > You don't need to compile kqemu into the kernel.  When I install
> > > dkms-kqemu from freshrpms, I do NOT rebuild my kernel.  I am fairly
> > > certain with Fedora's new policy for extras, there would not be much
> > > of a problem getting it added to Fedora.  For that matter, it could
> > > probably get added into the new Enterprise Extra's repository as
> > > well.  However, someone would need to volunteer to maintain the package.
> >
> > no thats not true fedora want to change the policy about out of tree
> > modules the want to drop all kmod-* packages and only allow modules into
> > the kernel rpm that are upstream or about to get merged upstream.
> > anyway why has kqemu to be a out of tree module?
>
> Mainly because the kernel already has one perfectly good virtualization
> interface. There's very little motivation to add another incompatible one,
> especially when the implementation is known to be fundamentally flawed, and
> probably insecure.
>
> If you really want to get it merged I suggest modifying kqemu to use the kvm
> interface, augmenting the kvm interface if necessary.
>
> Paul
>
>
>

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Paul Brook]

> > Mainly because the kernel already has one perfectly good virtualization
> > interface. There's very little motivation to add another incompatible
> > one, especially when the implementation is known to be fundamentally
> > flawed, and probably insecure.
> >
> > If you really want to get it merged I suggest modifying kqemu to use the
> > kvm interface, augmenting the kvm interface if necessary.
>
> Are you referring to the API when you say interface, or the
> functionality itself?  If the former that's a reasonable argument, but
> the latter is not valid since KVM requires a VT or AMD-V-capable
> processor, right?  KQEMU does not, and therefore [today] works on a
> much larger installed base of hardware.

Yes, I mean the API.  However in practice you'd probably want to try and share 
the implementation as well.  In short it's likely to need rewriting before 
it's acceptable upstream.

Paul

P.S. Please don't top-post. Consider this your final warning.

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Christian MICHON]

On 8/16/07, Paul Brook <paul@codesourcery.com> wrote:
> Yes, I mean the API.  However in practice you'd probably want to try and share
> the implementation as well.  In short it's likely to need rewriting before
> it's acceptable upstream.
>
> Paul
>
> P.S. Please don't top-post. Consider this your final warning.
>

blame it on gmail. this is the default behaviour.
it's obviously not intended...

-- 
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Ed Swierk]

On 8/16/07, Christian MICHON <christian.michon@gmail.com> wrote:
> blame it on gmail. this is the default behaviour.
> it's obviously not intended...

At the risk of drifting further off-topic, I'd just point out that you
can press Ctrl-End in the Gmail message window before you type your
reply.

--Ed

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Jernej Simonèiè]

On Thursday, August 16, 2007, 15:49:14, Paul Brook wrote:

> Mainly because the kernel already has one perfectly good virtualization
> interface.

Weren't both Xen and lguest recently merged to the (upcoming) 2.6.23
kernel?

-- 
< Jernej Simonèiè ><><><><>< http://deepthought.ena.si/ >

If it looks easy, it's tough. If it looks tough, it's damn near impossible.
       -- Stockmayer's Theorem

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Daniel P. Berrange]

On Thu, Aug 16, 2007 at 05:01:42PM +0200, Jernej Simon?i? wrote:
> On Thursday, August 16, 2007, 15:49:14, Paul Brook wrote:
> 
> > Mainly because the kernel already has one perfectly good virtualization
> > interface.
> 
> Weren't both Xen and lguest recently merged to the (upcoming) 2.6.23
> kernel?

They're different to this scenario.  Xen & lguest are Host <-> Guest  ABIs,
and both ultimately use the common paravirt_ops API inside the kernel.

kqemu & kvm are Host Kernel <-> Host Userspace APIs, which are completely
different, sharing no commonality in their APIs.  kqemu stands very little
chance getting merged unless it can share its userspace API model with KVM.
This would have the added advantage that the QEMU binary would only need
to talk one protocol to the kernel too, removing the need for the fork
between plain QEMU & KVM-ified QEMU.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Luke -Jr]

On Thursday 16 August 2007, Paul Brook wrote:
> If you really want to get it merged I suggest modifying kqemu to use the
> kvm interface, augmenting the kvm interface if necessary.

This sounds like the way to go.

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Bill C. Riemers]

dragoran wrote:
> Bill C. Riemers wrote:
>> You don't need to compile kqemu into the kernel.  When I install
>> dkms-kqemu from freshrpms, I do NOT rebuild my kernel.  I am fairly
>> certain with Fedora's new policy for extras, there would not be much
>> of a problem getting it added to Fedora.  For that matter, it could
>> probably get added into the new Enterprise Extra's repository as
>> well.  However, someone would need to volunteer to maintain the package.
> no thats not true fedora want to change the policy about out of tree
> modules the want to drop all kmod-* packages and only allow modules
> into the kernel rpm that are upstream or about to get merged upstream.
> anyway why has kqemu to be a out of tree module?
It looks like you are right.  Apparently the plan is to move the
acceptance of kernel modules to kernel maintainers.  For the most part,
they only want to accept very cleanly written modules that are likely to
be integrated into the kernel.  Since "kqemu" is viewed as a solution
only for obsolete hardware, that is not likely to happen.  It is a shame
too, because "kqemu" provides a quality working solution for most of the
hardware still in use today.

Bill

Re: [Qemu-devel] merging kqemu into mainline kernel?

[dragoran]

Bill C. Riemers wrote:
> dragoran wrote:
>   
>> Bill C. Riemers wrote:
>>     
>>> You don't need to compile kqemu into the kernel.  When I install
>>> dkms-kqemu from freshrpms, I do NOT rebuild my kernel.  I am fairly
>>> certain with Fedora's new policy for extras, there would not be much
>>> of a problem getting it added to Fedora.  For that matter, it could
>>> probably get added into the new Enterprise Extra's repository as
>>> well.  However, someone would need to volunteer to maintain the package.
>>>       
>> no thats not true fedora want to change the policy about out of tree
>> modules the want to drop all kmod-* packages and only allow modules
>> into the kernel rpm that are upstream or about to get merged upstream.
>> anyway why has kqemu to be a out of tree module?
>>     
> It looks like you are right.  Apparently the plan is to move the
> acceptance of kernel modules to kernel maintainers.  For the most part,
> they only want to accept very cleanly written modules that are likely to
> be integrated into the kernel.  Since "kqemu" is viewed as a solution
> only for obsolete hardware, that is not likely to happen. 
I am not sure that working on older hardware will keep it out of the 
kernel. it adds support for unsupported hardware .... I don't see a 
problem here.
>  It is a shame
> too, because "kqemu" provides a quality working solution for most of the
> hardware still in use today.
>
>   
we should atleast try to get it in ... the "it wont get merged anyway" 
attitude isn't very helpfull.

Re: [Qemu-devel] merging kqemu into mainline kernel?

[Sunil Amitkumar Janki]

dragoran wrote:
>> It looks like you are right.  Apparently the plan is to move the
>> acceptance of kernel modules to kernel maintainers.  For the most part,
>> they only want to accept very cleanly written modules that are likely to
>> be integrated into the kernel.  Since "kqemu" is viewed as a solution
>> only for obsolete hardware, that is not likely to happen. 
> I am not sure that working on older hardware will keep it out of the 
> kernel. it adds support for unsupported hardware .... I don't see a 
> problem here.
>>  It is a shame
>> too, because "kqemu" provides a quality working solution for most of the
>> hardware still in use today.
>>
>>   
> we should atleast try to get it in ... the "it wont get merged anyway" 
> attitude isn't very helpfull.

I hope the kqemu module could be either updated and merged as it is or
its functionality, i.e. not hardware assisted acceleration, integrated into
the kvm module (if possible). The latter would be an adequate solution
for x86, but what about other architectures?

Over the past few months I have added both MIPS and SPARC based
systems to my collection and I would like to have some kind of acceleration
of guests for those as well, short of recreating VMware for both.

The operating system running on all architectures is the same, so why
support one over the other? I understand x86 is the dominant architecture
for general purpose computing at the moment, but UltraSPARC T1/T2,
Loongson, Cell and future IA64 processors are changing all of that.

Sunil