[Qemu-devel] Killing KQEMU

[Qemu-devel] Killing KQEMU

[Chris Frey]

Hi,

I feel that I should post here, for the simple reason that most QEMU
users likely don't read this list, and have no idea that developers are
striving to kill off a valued feature.

This is a very valuable feature to me, as one of those users, and I find
it sad to read the eagerness some have at getting rid of it.  Not everyone
has access to the most modern hardware.  And not all hardware is worth
throwing out just because it doesn't have a CPU capable of virtualization.

I read excuses such as "it's not documented" and "nobody understands it"
and "there's no maintainer", but in a project such as QEMU, that is nearly
500,000 lines of code, the KQEMU kernel module clocks in, for linux,
at a whopping 674 lines.

I find it hard to believe that these 674 lines of code are too much for
the substantial braintrust available on this list.

Wasn't KQEMU written in the first place to be small, auditable, and
secure?  What has changed that it is now such a burden?

Thanks,
- Chris

Re: [Qemu-devel] Killing KQEMU

[Avi Kivity]

Chris Frey wrote:
> Hi,
>
> I feel that I should post here, for the simple reason that most QEMU
> users likely don't read this list, and have no idea that developers are
> striving to kill off a valued feature.
>
> This is a very valuable feature to me, as one of those users, and I find
> it sad to read the eagerness some have at getting rid of it.  Not everyone
> has access to the most modern hardware.  And not all hardware is worth
> throwing out just because it doesn't have a CPU capable of virtualization.
>
> I read excuses such as "it's not documented" and "nobody understands it"
> and "there's no maintainer", but in a project such as QEMU, that is nearly
> 500,000 lines of code, the KQEMU kernel module clocks in, for linux,
> at a whopping 674 lines.
>
> I find it hard to believe that these 674 lines of code are too much for
> the substantial braintrust available on this list.
>   

kqemu is a lot larger than 674 lines; what you're looking at is probably 
the glue module from the pre-GPL days that loads into the kernel and 
links into the real kqemu which was supplied as  a binary.

> Wasn't KQEMU written in the first place to be small, auditable, and
> secure?  

kqemu is not small, not auditable, and not secure.

> What has changed that it is now such a burden?
>   

Fabrice left.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] Killing KQEMU

[Rick Vernam]

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

On Monday 01 June 2009 10:52:17 pm Chris Frey wrote:
> Hi,
>
> I feel that I should post here, for the simple reason that most QEMU
> users likely don't read this list, and have no idea that developers are
> striving to kill off a valued feature.
>
> This is a very valuable feature to me, as one of those users, and I find
> it sad to read the eagerness some have at getting rid of it.  Not everyone
> has access to the most modern hardware.  And not all hardware is worth
> throwing out just because it doesn't have a CPU capable of virtualization.

First, I am in the same class as you: no hardware extensions for 
virtualization, and I'm not going to buy new hardware for that alone.
I haven't seen anything that I consider eagerness to get rid of KQemu, perhaps 
you've read something off list or I've missed something on list?  I am curious.

And to any devs who are eager to rid Qemu of KQemu - first, thanks for Qemu :-) 
... but also, why are you eager to rid Qemu of KQemu?  (this is not a 
rhetorical question - very sincere question.  I'm looking to learn here...)
I understand that KQemu is perhaps sub-optimal in some or many ways, and/or 
abandoned.  Does keeping the KQemu-supporting bits in Qemu cause some 
hindrance in developing other features?

Anyway, thanks for all your work.  In case there really is any eagerness to 
kill off KQemu, I'm just dropping a friendly reminder that there are some 
grateful folks out here who do actually use KQemu :-)

>
> I read excuses such as "it's not documented" and "nobody understands it"
> and "there's no maintainer", but in a project such as QEMU, that is nearly
> 500,000 lines of code, the KQEMU kernel module clocks in, for linux,
> at a whopping 674 lines.
>
> I find it hard to believe that these 674 lines of code are too much for
> the substantial braintrust available on this list.
>
> Wasn't KQEMU written in the first place to be small, auditable, and
> secure?  What has changed that it is now such a burden?
>
> Thanks,
> - Chris


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

Re: [Qemu-devel] Killing KQEMU

[Gleb Natapov]

On Mon, Jun 01, 2009 at 11:52:17PM -0400, Chris Frey wrote:
> Hi,
> 
> I feel that I should post here, for the simple reason that most QEMU
> users likely don't read this list, and have no idea that developers are
> striving to kill off a valued feature.
> 
> This is a very valuable feature to me, as one of those users, and I find
> it sad to read the eagerness some have at getting rid of it.  Not everyone
> has access to the most modern hardware.  And not all hardware is worth
> throwing out just because it doesn't have a CPU capable of virtualization.
> 
If it works for you then use it! Just stay with the last version that
support kqemu. Nobody going to chase all mirrors and remove older
version from there and nobody is going to remove it from git history.

> I read excuses such as "it's not documented" and "nobody understands it"
> and "there's no maintainer", but in a project such as QEMU, that is nearly
> 500,000 lines of code, the KQEMU kernel module clocks in, for linux,
> at a whopping 674 lines.
> 
> I find it hard to believe that these 674 lines of code are too much for
> the substantial braintrust available on this list.
> 
> Wasn't KQEMU written in the first place to be small, auditable, and
> secure?  What has changed that it is now such a burden?
> 
If it matters enough for you you'll start to maintain it (it is sooo easy
after all) or will pay someone to maintain it.

--
			Gleb.

Re: [Qemu-devel] Killing KQEMU

[Avi Kivity]

Avi Kivity wrote:
>> I find it hard to believe that these 674 lines of code are too much for
>> the substantial braintrust available on this list.
>>   
>
> kqemu is a lot larger than 674 lines; what you're looking at is 
> probably the glue module from the pre-GPL days that loads into the 
> kernel and links into the real kqemu which was supplied as  a binary.

kqemu weighs in at more than 14,000 lines of pretty complicated code.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] Killing KQEMU

[Anton D Kachalov]

On 02.06.2009 07:52, Chris Frey wrote:
> Hi,
>
> I feel that I should post here, for the simple reason that most QEMU
> users likely don't read this list, and have no idea that developers are
> striving to kill off a valued feature.
>    
[...]

Chris,

I may suggest you to switch to VirtualBox / VirtualBox OSE that has more 
features (comparable to VmWare) if you're interested to use QEMU just to 
run some kind of OS. It's much faster than QEMU + kqemu. And more over, 
it's stable. Sometimes I have software fails (segfaults in Java JIT) 
with QEMU+kqemu, but VBox drives well.

If you're HW/FW developer, you doesn't need kqemu at all.

Rgds,
Anton

Re: [Qemu-devel] Killing KQEMU

[Paul Brook]

> And to any devs who are eager to rid Qemu of KQemu - first, thanks for Qemu
> :-) ... but also, why are you eager to rid Qemu of KQemu?  (this is not a
> rhetorical question - very sincere question.  I'm looking to learn here...)
> I understand that KQemu is perhaps sub-optimal in some or many ways, and/or
> abandoned.  Does keeping the KQemu-supporting bits in Qemu cause some
> hindrance in developing other features?

osdep.c:/* FIXME: This file should be target independent. However it has kqemu
vl.c:    /* FIXME: This is a nasty hack because kqemu can't cope with dynamic
cpu-common.h: #ifdef CONFIG_KQEMU /* FIXME: This is wrong.  */
exec.c: #elif defined(TARGET_X86_64) && !defined(CONFIG_KQEMU)

If you want kqemu to continue existing, you need to find someone to actively 
maintain it. IMO at bare minimum all the above need to go away. AFAIK there's 
not currently anyone has the time/inclination to do this, and from most 
accounts kqemu doesn't really work very reliably at the best of times.

Or let me put it another way: At some point I'll get fed up of the limitations 
that kqemu currently imposes, and deliberately break it. If it remains broken 
then it will be removed. You get to decide whether you want to fix kqemu, 
start again from scratch (probably enhancing KVM), or keep using old versions 
of qemu.

As I've said before, if you're serious about maintaining kqemu you probably 
need to get it integrated into mainstream kernels. Without this a large 
portion of the relevant communities simply aren't going to care.

Paul

[Qemu-devel] Re: Killing KQEMU

[Chris Frey]

On Tue, Jun 02, 2009 at 09:28:50AM +0300, Avi Kivity wrote:
> kqemu weighs in at more than 14,000 lines of pretty complicated code.

Yes, my line count was way off.  Thanks for the correction.

- Chris

[Qemu-devel] Re: Killing KQEMU

[Chris Frey]

On Tue, Jun 02, 2009 at 01:26:27PM +0400, Anton D Kachalov wrote:
> I may suggest you to switch to VirtualBox / VirtualBox OSE that has more 
> features (comparable to VmWare) if you're interested to use QEMU just to 
> run some kind of OS.

"Just to run some kind of OS" is the task that the majority of virtualization
users are looking for.  It makes it sound like that's not the audience
that QEMU is trying to serve.

I'd give VirtualBox OSE a try, if it supported USB.  QEMU is the only
open virtualization system that reasonably supports old hardware and USB.
At least to my knowledge.

Without kqemu, that reasonable support for old hardware disappears, and USB
has only become useful recently.  USB under 0.9.x was pain incarnate.

- Chris

[Qemu-devel] Re: Killing KQEMU

[Chris Frey]

On Tue, Jun 02, 2009 at 01:54:30PM +0100, Paul Brook wrote:
> osdep.c:/* FIXME: This file should be target independent. However it has kqemu
> vl.c:    /* FIXME: This is a nasty hack because kqemu can't cope with dynamic
> cpu-common.h: #ifdef CONFIG_KQEMU /* FIXME: This is wrong.  */
> exec.c: #elif defined(TARGET_X86_64) && !defined(CONFIG_KQEMU)

These are fairly small annoyances, no?  I'm assuming they are, since they
exist at all, considering the frustration evident in:


> Or let me put it another way: At some point I'll get fed up of the
> limitations that kqemu currently imposes, and deliberately break it.

I would hope that anyone who deliberately breaks kqemu support would be
kind enough to post that fact to the mailing list, with a description of
what's broken and why, so that others may step up to the plate and fix it.

Breaking something deliberately and quietly, only to use it later as an
excuse to remove the feature could be seen as anti-social.


> If it remains broken then it will be removed. You get to decide whether
> you want to fix kqemu, start again from scratch (probably enhancing KVM),
> or keep using old versions of qemu.

The KVM website (http://www.linux-kvm.org/) states very clearly that its
goal is for systems that support virtualization extensions.  Is it possible
to write a pluggable KQEMU backend to KVM, for old systems, that QEMU could
use blindly as a native KVM system?  How open are the KVM developers to API
changes imposed by KQEMU-like functionality?


> As I've said before, if you're serious about maintaining kqemu you probably 
> need to get it integrated into mainstream kernels. Without this a large 
> portion of the relevant communities simply aren't going to care.

According to other threads on this list, it would appear that getting
KQEMU into the kernel is often thought of as impossible, or "would never
happen."  So this isn't really a solution either.

- Chris

Re: [Qemu-devel] Re: Killing KQEMU

[Avi Kivity]

Chris Frey wrote:
> On Tue, Jun 02, 2009 at 01:54:30PM +0100, Paul Brook wrote:
>   
>> osdep.c:/* FIXME: This file should be target independent. However it has kqemu
>> vl.c:    /* FIXME: This is a nasty hack because kqemu can't cope with dynamic
>> cpu-common.h: #ifdef CONFIG_KQEMU /* FIXME: This is wrong.  */
>> exec.c: #elif defined(TARGET_X86_64) && !defined(CONFIG_KQEMU)
>>     
>
> These are fairly small annoyances, no?  

Not supporting >2GB guests is a large annoyance (very large if you have 
128GB of RAM).  Don't know about the others.  I think kqemu also blocks 
memory hotplug.

>> Or let me put it another way: At some point I'll get fed up of the
>> limitations that kqemu currently imposes, and deliberately break it.
>>     
>
> I would hope that anyone who deliberately breaks kqemu support would be
> kind enough to post that fact to the mailing list, with a description of
> what's broken and why, so that others may step up to the plate and fix it.
>
> Breaking something deliberately and quietly, only to use it later as an
> excuse to remove the feature could be seen as anti-social.
>   

If you're stepping up I can point out the problems I'm aware of.

>> If it remains broken then it will be removed. You get to decide whether
>> you want to fix kqemu, start again from scratch (probably enhancing KVM),
>> or keep using old versions of qemu.
>>     
>
> The KVM website (http://www.linux-kvm.org/) states very clearly that its
> goal is for systems that support virtualization extensions.  Is it possible
> to write a pluggable KQEMU backend to KVM, for old systems, that QEMU could
> use blindly as a native KVM system?  

It is possible, however it is a very difficult undertaking.

> How open are the KVM developers to API
> changes imposed by KQEMU-like functionality?
>   

Clean, unintrusive patches will be accepted, if there is a commitment to 
maintain them.

>> As I've said before, if you're serious about maintaining kqemu you probably 
>> need to get it integrated into mainstream kernels. Without this a large 
>> portion of the relevant communities simply aren't going to care.
>>     
>
> According to other threads on this list, it would appear that getting
> KQEMU into the kernel is often thought of as impossible, or "would never
> happen."  So this isn't really a solution either.

kqemu as is is probably unmergable.  Your best bet is though kvm since 
that already has the interfaces defined and accepted (as well as large 
chunks of code like the mmu and x86 emulator that can be reused.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

[Qemu-devel] Re: Killing KQEMU

[Paul Brook]

>> osdep.c:/* FIXME: This file should be target independent. However it has
>> kqemu vl.c:    /* FIXME: This is a nasty hack because kqemu can't cope
>> with dynamic cpu-common.h: #ifdef CONFIG_KQEMU /* FIXME: This is wrong. 
>> */
>> exec.c: #elif defined(TARGET_X86_64) && !defined(CONFIG_KQEMU)
>
>These are fairly small annoyances, no?  I'm assuming they are, since they
>exist at all, considering the frustration evident in:

They're horrid hacks that I only reluctantly created in the first place. 
Limiting guest physical memory to 4G is a fairly serous issue. Requiring the 
user specify how much ram they require upfront will not be acceptable once we 
have machine config files.

>> Or let me put it another way: At some point I'll get fed up of the
>> limitations that kqemu currently imposes, and deliberately break it.
>
>I would hope that anyone who deliberately breaks kqemu support would be
>kind enough to post that fact to the mailing list

Sure, but this is actually part of my point.  If noone cares enough to 
track+test the development branch, then it just proves how little anyone 
actually cares about kqemu.

> > As I've said before, if you're serious about maintaining kqemu you
> > probably need to get it integrated into mainstream kernels. Without this
> > a large portion of the relevant communities simply aren't going to care.
>
> According to other threads on this list, it would appear that getting
> KQEMU into the kernel is often thought of as impossible, or "would never
> happen."

In its current form that's probably true. It may effectively require a 
complete rewrite.

OTOH kqemu has some fairly serious bugs, and may need a complete rewrite to 
fix those bugs.  IMHO current kqemu is effectively unsupportable[1] for any 
serious use, which is one of the reasons I'm not concerned about it going away 
in the near future.

Paul

[1] Unsupportable == I'm not letting it anywhere near my production systems. 
When it breaks you keep both pieces, and it's unlikely anyone knows how to 
glue them back together again.

Re: [Qemu-devel] Re: Killing KQEMU

[Gerd Hoffmann]

On 06/02/09 22:09, Chris Frey wrote:
> On Tue, Jun 02, 2009 at 01:54:30PM +0100, Paul Brook wrote:
>> osdep.c:/* FIXME: This file should be target independent. However it has kqemu
>> vl.c:    /* FIXME: This is a nasty hack because kqemu can't cope with dynamic
>> cpu-common.h: #ifdef CONFIG_KQEMU /* FIXME: This is wrong.  */
>> exec.c: #elif defined(TARGET_X86_64)&&  !defined(CONFIG_KQEMU)
>
> These are fairly small annoyances, no?  I'm assuming they are, since they
> exist at all, considering the frustration evident in:

One becoming more and more annonying as machine sizes grow is that kqemu 
can't handle more than 4GB of guest memory even on 64bit hosts.  And it 
is a compile time, not a runtime dependency, i.e. the same limit is 
forced on the qemu binary too.  To run big guests you have to build qemu 
without kqemu support.

I think that one is #4 in the list above.

>> Or let me put it another way: At some point I'll get fed up of the
>> limitations that kqemu currently imposes, and deliberately break it.
>
> I would hope that anyone who deliberately breaks kqemu support would be
> kind enough to post that fact to the mailing list, with a description of
> what's broken and why, so that others may step up to the plate and fix it.

Removing the 4GB limit mentioned from the qemu code base above will make 
kqemu stop working.

cheers,
   Gerd

Re: [Qemu-devel] Re: Killing KQEMU

[Stuart Brady]

On Tue, Jun 02, 2009 at 04:09:18PM -0400, Chris Frey wrote:
> > Or let me put it another way: At some point I'll get fed up of the
> > limitations that kqemu currently imposes, and deliberately break it.
> 
> I would hope that anyone who deliberately breaks kqemu support would be
> kind enough to post that fact to the mailing list, with a description of
> what's broken and why, so that others may step up to the plate and fix it.

Perhaps so, but unless someone is actually going to fix kqemu or write a
replacement, I don't see what difference this really makes.

> According to other threads on this list, it would appear that getting
> KQEMU into the kernel is often thought of as impossible, or "would never
> happen."  So this isn't really a solution either.

More like "impossible because it *should* never happen".  kqemu is not
known to be secure.  I don't know what the position of developers for
kernels besides Linux is on this, but it's hardly the point, tbh...
-- 
Stuart Brady

[Qemu-devel] Re: Re: Killing KQEMU

[Chris Frey]

On Tue, Jun 02, 2009 at 09:47:14PM +0100, Stuart Brady wrote:
> On Tue, Jun 02, 2009 at 04:09:18PM -0400, Chris Frey wrote:
> > I would hope that anyone who deliberately breaks kqemu support would be
> > kind enough to post that fact to the mailing list, with a description of
> > what's broken and why, so that others may step up to the plate and fix it.
> 
> Perhaps so, but unless someone is actually going to fix kqemu or write a
> replacement, I don't see what difference this really makes.

The difference is that people that use kqemu would know the very latest
commit that supports kqemu before it was broken deliberately.  I'm assuming
I'm not the only one who compiles the latest git every so often and
hopes it works with kqemu.


> More like "impossible because it *should* never happen".  kqemu is not
> known to be secure.

Did you mean "kqemu is known to not be secure" or is this just FUD?

The KQEMU technical documentation on the QEMU website specifically
stresses that no VM code is run at kernel level, so someone was thinking
about security when it was written.

Running something like the single-module KQEMU is a lot safer than running
the VMWare binary blobs, in my opinion, unless there are known security
holes in it that have not been fixed.  In which case, I'm quite interested
to know, as it might affect my cheerleading for it. :-)

- Chris

[Qemu-devel] Re: Killing KQEMU

[Chris Frey]

On Tue, Jun 02, 2009 at 09:30:42PM +0100, Paul Brook wrote:
> They're horrid hacks that I only reluctantly created in the first place. 
> Limiting guest physical memory to 4G is a fairly serous issue. Requiring the 
> user specify how much ram they require upfront will not be acceptable once we 
> have machine config files.

I see.  Let me thank you then for adding those hacks.  I'm a user
that truly appreciates it.


> Sure, but this is actually part of my point.  If noone cares enough to 
> track+test the development branch, then it just proves how little anyone 
> actually cares about kqemu.

I do.  I can't do it every day, but every so often I do a git fetch and
try it out.  I can report that Fedora 10 hangs during boot using kqemu
1.4.0pre1 and git 34aee2552fb5f4329d59a60f939656214b26d7f8 (0.10.4),
but that if I can coax it past the startup of services, it runs fine
after that.  That coaxing is easier said than done, though, so I'm assuming
it is some kind of kqemu race.  Unfortunately, I have no more data than that,
and not enough expertise yet to find out why.


> [1] Unsupportable == I'm not letting it anywhere near my production systems. 
> When it breaks you keep both pieces, and it's unlikely anyone knows how to 
> glue them back together again.

That's understandable.  But for a developer like me, kqemu sure saves a lot
of time when it works.

- Chris

Re: [Qemu-devel] Re: Killing KQEMU

[Rick Vernam]

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

On Wednesday 03 June 2009 4:34:49 pm Chris Frey wrote:
> On Tue, Jun 02, 2009 at 09:30:42PM +0100, Paul Brook wrote:
> > They're horrid hacks that I only reluctantly created in the first place.
> > Limiting guest physical memory to 4G is a fairly serous issue. Requiring
> > the user specify how much ram they require upfront will not be acceptable
> > once we have machine config files.
>
> I see.  Let me thank you then for adding those hacks.  I'm a user
> that truly appreciates it.
>
> > Sure, but this is actually part of my point.  If noone cares enough to
> > track+test the development branch, then it just proves how little anyone
> > actually cares about kqemu.
>
> I do.  I can't do it every day, but every so often I do a git fetch and
> try it out.  I can report that Fedora 10 hangs during boot using kqemu
> 1.4.0pre1 and git 34aee2552fb5f4329d59a60f939656214b26d7f8 (0.10.4),
> but that if I can coax it past the startup of services, it runs fine
> after that.  That coaxing is easier said than done, though, so I'm assuming
> it is some kind of kqemu race.  Unfortunately, I have no more data than
> that, and not enough expertise yet to find out why.

Likewise, I do the same.  I have documented a few issues I've come across, but 
when I could no longer debug with my current level of experience I just 
dropped it.  I just don't have the time to ascend the learning curve - another 
way of saying I don't care *enough* ...

>
> > [1] Unsupportable == I'm not letting it anywhere near my production
> > systems. When it breaks you keep both pieces, and it's unlikely anyone
> > knows how to glue them back together again.
>
> That's understandable.  But for a developer like me, kqemu sure saves a lot
> of time when it works.
>
> - Chris


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

[Qemu-devel] Re: Re: Killing KQEMU

[Chris Frey]

On Tue, Jun 02, 2009 at 11:24:11PM +0300, Avi Kivity wrote:
> Not supporting >2GB guests is a large annoyance (very large if you have 
> 128GB of RAM).  Don't know about the others.  I think kqemu also blocks 
> memory hotplug.

Even if I were to fix kqemu to support such guests, I'd have no way to
test it, with test machine specs like that.

People say on this list that nobody wants to write for old hardware, but
kernel developers (and apparently QEMU developers) are so far ahead of
the curve that they forget that a system with 1GB of RAM may be someone's
most powerful machine.

Someone with 128GB in their machine obviously doesn't need to care about
a minor speed boost from kqemu.  It's slower than their native hardware.


> If you're stepping up I can point out the problems I'm aware of.

I'm most interested in easing the pain of keeping kqemu alive.  It seems
like valuable tech that should not be thrown away just yet.

What can I, a non-expert, do to help ease the pain that does not involve
a rewrite or a porting to KVM?  I'm very competent in C and have hacked
the kernel a bit, but QEMU is new territory.


> >The KVM website (http://www.linux-kvm.org/) states very clearly that its
> >goal is for systems that support virtualization extensions.  Is it possible
> >to write a pluggable KQEMU backend to KVM, for old systems, that QEMU could
> >use blindly as a native KVM system?  
> 
> It is possible, however it is a very difficult undertaking.

Likely beyond my abilities at the moment.

My first step would be to learn how to debug hangs caused by kqemu and
submit patches to fix those bugs.  Any pointers to documentation you can
provide?

I see this link:
http://www.h7.dion.ne.jp/~qemu-win/DebuggingTips-en.html

I'm hoping there's more.

Thanks,
- Chris

Re: [Qemu-devel] Re: Re: Killing KQEMU

[Paul Brook]

> > More like "impossible because it *should* never happen".  kqemu is not
> > known to be secure.
>
> Did you mean "kqemu is known to not be secure" or is this just FUD?

AFAIK noone has produced a real-work exploit, but see below.

> The KQEMU technical documentation on the QEMU website specifically
> stresses that no VM code is run at kernel level, so someone was thinking
> about security when it was written.

Absolutely not.

The fact that all guest code is run in ring3 is in no way in indication that 
the end result is secure. I know from experience[1] that there are many ways 
that such a VM an be compromised. Pretty much every mainstream x86 operating 
system in the last 15 years runs application code in ring3, but that doesn't 
mean they're even vaguely secure.

My understanding is that kqemu is known to not work correctly under certain 
circumstances. It's possible that this never occurs when common guest 
operating systems are operating normally. However if a guest is compromised it 
is likely that it will be able to either compromise or DoS(crash) the host 
machine.  Empirical evidence suggests that in practice this happens even 
without malicious intent.

Paul

[1] I wrote a prototype kqemu equivalent, so have been intimately familiar 
with many of the things that can go wrong.

[Qemu-devel] Re: Killing KQEMU

[Avi Kivity]

Chris Frey wrote:
> On Tue, Jun 02, 2009 at 11:24:11PM +0300, Avi Kivity wrote:
>   
>> Not supporting >2GB guests is a large annoyance (very large if you have 
>> 128GB of RAM).  Don't know about the others.  I think kqemu also blocks 
>> memory hotplug.
>>     
>
> Even if I were to fix kqemu to support such guests, I'd have no way to
> test it, with test machine specs like that.
>
> People say on this list that nobody wants to write for old hardware, but
> kernel developers (and apparently QEMU developers) are so far ahead of
> the curve that they forget that a system with 1GB of RAM may be someone's
> most powerful machine.
>   

You don't need to make kqemu run large guests, just stop it from 
preventing qemu and qemu/kvm from running large guests.  It's perfectly 
reasonable for kqemu to have some limitations.

>> If you're stepping up I can point out the problems I'm aware of.
>>     
>
> I'm most interested in easing the pain of keeping kqemu alive.  It seems
> like valuable tech that should not be thrown away just yet.
>
> What can I, a non-expert, do to help ease the pain that does not involve
> a rewrite or a porting to KVM?  I'm very competent in C and have hacked
> the kernel a bit, but QEMU is new territory.
>   

Start by finding out why kqemu insists on 32-bit page descriptors, and 
increase it to 64 bits.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Re: Killing KQEMU

[Andreas Färber]

Am 02.06.2009 um 22:30 schrieb Paul Brook:

> OTOH kqemu has some fairly serious bugs, and may need a complete  
> rewrite to
> fix those bugs.  IMHO current kqemu is effectively unsupportable[1]  
> for any
> serious use, which is one of the reasons I'm not concerned about it  
> going away
> in the near future.
>
> Paul
>
> [1] Unsupportable == I'm not letting it anywhere near my production  
> systems.

And that's exactly my point about KVM: What "production systems" are  
you talking of?! I doubt anyone today is using kqemu in their business  
for "serious use" like virtualizing servers. That's where you can tell  
people to buy recent hardware and to move to KVM.

But do you consider your private desktop computer a production  
environment? Development environment? Test environment? Pre-production  
environment? I guess it's all-in-one for most of us here, and we don't  
change it on a daily basis. Similar in CS institutions.

A very nice use case of QEMU is that it works cross-platform, cross- 
hardware.

I could have a virtual machine under Mac OS X on ppc at home, could  
take it on my i386 MacBook to university, run it e.g. on a non-KVM  
Fedora amd64 pool computer there, or on a Solaris amd64 server.
Or the other direction: We got/made disk images for courses at  
university and had to analyze them somewhere. Even with malicious root  
kits and stuff installed, we did not run into apparent issues  
virtualizing them.
With GbE connections you can easily transfer disk images around,  
accompanied by original checksums and a tiny shell script to run them  
- use cases that VMware, VirtualBox and KVM cannot keep up with yet.

Andreas

Re: [Qemu-devel] Re: Killing KQEMU

[Paul Brook]

> > [1] Unsupportable == I'm not letting it anywhere near my production
> > systems.

>And that's exactly my point about KVM: What "production systems" are
>you talking of?!

Any machine that isn't completely disposable. For most users this includes 
their local workstation.

> A very nice use case of QEMU is that it works cross-platform, cross-
> hardware.

This actually argues against using kqemu as it only works in on "native" 
hosts.

>Or the other direction: We got/made disk images for courses at
>university and had to analyze them somewhere. Even with malicious root
>kits and stuff installed, we did not run into apparent issues
>virtualizing them.

You've been lucky then. I bet the only reason you haven't seen any problems is 
because kqemu is too obscure for anyone to bother attacking it.

>With GbE connections you can easily transfer disk images around,
>accompanied by original checksums and a tiny shell script to run them
>- use cases that VMware, VirtualBox and KVM cannot keep up with yet.

Neither can kqemu. Installing an unsupported third party kernel module is 
about the worst thing you can do from a security and stability standpoint. I'd 
expect any respectably sysadmin to laugh and kick you out if you requested 
they do this on any of their shared machines.

Paul

Re: [Qemu-devel] Re: Killing KQEMU

[Andreas Färber]

Am 06.06.2009 um 13:27 schrieb Paul Brook:

>> A very nice use case of QEMU is that it works cross-platform, cross-
>> hardware.
>
> This actually argues against using kqemu as it only works in on  
> "native"
> hosts.

Nope. It means that I can easily interchange identical VMs between  
accelerated (e.g. kqemu) and unaccelerated emulators. It works great,  
with the same command line[1], since it does not appear to change the  
hardware configuration [2].

This does not rule out KVM as future replacement, obviously, if KVM- 
specific things like virtio etc. do not interfere.
But still dropping kqemu means having an unaccelerated emulation on  
those machines not capable of running KVM due to hardware, OS or KVM- 
versioning issues.

Andreas

[1] assuming no -kernel-kqemu
[2] as opposed to moving guest images between different virtualization/ 
emulation solutions

Re: [Qemu-devel] Re: Killing KQEMU

[Gleb Natapov]

On Sat, Jun 06, 2009 at 03:50:26PM +0200, Andreas Färber wrote:
>
> Am 06.06.2009 um 13:27 schrieb Paul Brook:
>
>>> A very nice use case of QEMU is that it works cross-platform, cross-
>>> hardware.
>>
>> This actually argues against using kqemu as it only works in on  
>> "native"
>> hosts.
>
> Nope. It means that I can easily interchange identical VMs between  
> accelerated (e.g. kqemu) and unaccelerated emulators. It works great,  
> with the same command line[1], since it does not appear to change the  
> hardware configuration [2].
>
> This does not rule out KVM as future replacement, obviously, if KVM- 
> specific things like virtio etc. do not interfere.
There is nothing KVM specific in virtio.

> But still dropping kqemu means having an unaccelerated emulation on  
> those machines not capable of running KVM due to hardware, OS or KVM- 
> versioning issues.
>
> Andreas
>
> [1] assuming no -kernel-kqemu
> [2] as opposed to moving guest images between different virtualization/ 
> emulation solutions
>
>

--
			Gleb.

Re: [Qemu-devel] Re: Killing KQEMU

[Avi Kivity]

Andreas Färber wrote:
>
> This does not rule out KVM as future replacement, obviously, if 
> KVM-specific things like virtio etc. do not interfere.

virtio is not kvm-specific.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.