qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "René Rebe" <rene@exactcode.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: Cutting a new QEMU release
Date: Fri, 06 Feb 2009 16:57:00 +0100	[thread overview]
Message-ID: <498C5DCC.3060106@exactcode.de> (raw)
In-Reply-To: <1233917676.6637.39.camel@ecrins.fosdick.home.net>

Hi,

Steve Fosdick wrote:
> On Thu, 2009-02-05 at 13:03 -0600, Anthony Liguori wrote:
>
>   
>> Personally, I'd prefer that it lived outside of the QEMU tree.  It is 
>> never going to go into upstream Linux and it's not something that I 
>> think is worth supporting.
>>     
>
> Does anyone here have any stats on what people are using QEMU for?
>
> I ask this because I suspect a significant use case is running an x86
> guest on an x86 host and, at the moment, the only way to get reasonable
> performance on a non virtualisation-enhanced CPU seems to be to use
> kqmeu.
>
> Now, I can understand the developers of kvm only supporting the
> virtualisation-enhanced CPUs because, looking to the future they will be
> common.  I suspect at the moment though there are plenty of people
> running VMs on older hardware.
>
> I can also see that if it would take major refactoring to get kqemu into
> the main kernal tree it is probably not worth the efforts as, by the
> time that work is complete the ratio virtualisation-enhanced CPUs to
> older, non virtualisation-enhanced CPUs would be higher.
>
> To my mind mind, what would be good right now is if someone (or some
> people) understands kqemu well enough that, if kernel changes break it,
> it can be fixed, not forever but until more people have
> virtualisation-enhanced CPUs and can use KVM instead.
>   
Indeed. Though I used KVM for the past months to do Linux development
and system testing / integration I had a use case for kqemu (non-VT CPU)
just this week and was surprised to find quite "old" kqemu release just 
build
and work for booth 2.6.26 and 2.6.28. And so far there was no problem with
it.

While I have no problem having it long time ported to the KVM interface,
just declaring some quite useful and functional piece of open source work
obsolete and unsupported quite drastic. This work should be not be lost
so easily.

When kqemu is supposed to be gotten upstream the question remains what
to do with the freebsd, windows, solaris, etc. glue code.

If I would know more of the internals of kqemu I would even volunteer to
maintain it - however, I just took the first look at it yesterday which does
not really qualify to maintain it just yet. Though I would work on getting
it adapted on future kernel changes, and/or even hunt a bug if it starts
crashing in one or another scenario for me (but right now I have to hunt
some crashing with 32bit host KVM for a start).

Yours,

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name

  reply	other threads:[~2009-02-06 15:57 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-05  9:13 [Qemu-devel] Re: Cutting a new QEMU release Steve Fosdick
2009-02-05 14:26 ` Anthony Liguori
2009-02-05 15:36   ` Rick Vernam
2009-02-05 16:27     ` Paul Brook
2009-02-05 17:15       ` René Rebe
2009-02-05 17:36         ` Paul Brook
2009-02-05 17:51           ` Daniel P. Berrange
2009-02-05 17:51       ` Ben Taylor
2009-02-05 18:39         ` René Rebe
2009-02-05 19:03         ` Anthony Liguori
2009-02-06 10:54           ` Steve Fosdick
2009-02-06 15:57             ` René Rebe [this message]
2009-02-06 17:12               ` Anthony Liguori
2009-02-06 21:47                 ` René Rebe
2009-02-07 16:49                 ` Jamie Lokier
2009-02-07 17:06                   ` Laurent Desnogues
2009-02-07 23:46                   ` Anthony Liguori
2009-02-06 21:53               ` René Rebe
2009-02-07 16:39             ` Jamie Lokier
     [not found]           ` <92CAE88C-36FF-4566-BD1D-ACA58C98CB0F@hotmail.com>
2009-02-09  5:01             ` C.W. Betts
     [not found]               ` <784D2534-F9CD-4EA5-BBEE-67E9DE196598@hotmail.com>
2009-02-09  5:42                 ` C.W. Betts
2009-02-09 10:29                   ` René Rebe
2009-02-15 15:25         ` Andreas Färber
2009-02-15 15:44           ` Jamie Lokier
2009-02-15 19:14             ` Andreas Färber
2009-02-15 18:17           ` Anthony Liguori
2009-02-15 20:31             ` Andreas Färber
2009-02-05 15:55   ` René Rebe
2009-02-07 12:01   ` Stefan Weil
2009-02-07 15:08     ` Anthony Liguori
2009-02-07 15:36     ` Jamie Lokier
2009-02-07 16:45       ` Jan Kiszka
2009-02-05 14:55 ` Rick Vernam
  -- strict thread matches above, loose matches on Subject: below --
2009-02-03 20:48 [Qemu-devel] " Anthony Liguori
2009-02-04 14:50 ` Aurelien Jarno
2009-02-04 15:23   ` Tristan Gingold
2009-02-04 15:43     ` Lennart Sorensen
2009-02-04 16:01       ` Tristan Gingold
2009-02-04 18:17         ` [Qemu-devel] " Consul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=498C5DCC.3060106@exactcode.de \
    --to=rene@exactcode.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).