[Qemu-devel] Re: Cutting a new QEMU release

[Qemu-devel] Re: Cutting a new QEMU release

[Steve Fosdick]

Given the talk of a new release I though I'd try the latest qemu from
SVN.  At the moment I am being hampered by kqemu-1.4.0pre1 not compiling
though:

  CC [M]  /usr/src/kqemu-1.4.0pre1/kqemu-linux.o
/usr/src/kqemu-1.4.0pre1/kqemu-linux.c: In function
‘kqemu_lock_user_page’:
/usr/src/kqemu-1.4.0pre1/kqemu-linux.c:81: error: dereferencing pointer
to incomplete type
/usr/src/kqemu-1.4.0pre1/kqemu-linux.c: In function ‘kqemu_schedule’:
/usr/src/kqemu-1.4.0pre1/kqemu-linux.c:194: error: implicit declaration
of function ‘need_resched’
/usr/src/kqemu-1.4.0pre1/kqemu-linux.c:195: error: implicit declaration
of function ‘schedule’
/usr/src/kqemu-1.4.0pre1/kqemu-linux.c:197: error: implicit declaration
of function ‘signal_pending’
make[2]: *** [/usr/src/kqemu-1.4.0pre1/kqemu-linux.o] Error 1

This is with kernel 2.6.28.2. kqemu-1.3.0pre11 seems to compile OK with
the kernel.  Any ideas?

Regards,
Steve.

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Anthony Liguori]

Steve Fosdick wrote:
> Given the talk of a new release I though I'd try the latest qemu from
> SVN.  At the moment I am being hampered by kqemu-1.4.0pre1 not compiling
> though:
>
>   CC [M]  /usr/src/kqemu-1.4.0pre1/kqemu-linux.o
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c: In function
> ‘kqemu_lock_user_page’:
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:81: error: dereferencing pointer
> to incomplete type
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c: In function ‘kqemu_schedule’:
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:194: error: implicit declaration
> of function ‘need_resched’
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:195: error: implicit declaration
> of function ‘schedule’
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:197: error: implicit declaration
> of function ‘signal_pending’
> make[2]: *** [/usr/src/kqemu-1.4.0pre1/kqemu-linux.o] Error 1
>
> This is with kernel 2.6.28.2. kqemu-1.3.0pre11 seems to compile OK with
> the kernel.  Any ideas?
>   

kqemu is unsupported and unmaintained.

Regards,

Anthony Liguori

> Regards,
> Steve.
>
>
>   

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Rick Vernam]

On Thursday 05 February 2009 8:26:04 am Anthony Liguori wrote:
> kqemu is unsupported and unmaintained.
Interesting.  When did it fall into that status?
The Maintainers file shows Fabrice as the maintainer of kqemu.  I suppose that 
needs to be updated?

I see Fabrice released 1.4.0pre1 on May 30th, 2008, although I never did see 
anything declaring it unsupported (I'm not suggesting it was never declared, 
just that I never saw any such declaration).

Are there any plans to support it in the future?  This really is quite a shock 
to me, actually.  I know qemu has a wide range of uses - but for me and surely 
others, virtualization is a primary use.  To the best of my knowledge, kvm 
requires hardware support - where does this leave the class of users who need 
virtualization & don't have hardware virtualization support?  Are we no longer 
the a target audience of qemu?  If not, fine, but apparently a statement needs 
to be made...

Also, I had considered the web site at http://bellard.org/qemu/ to be 
accurate.  Perhaps something should be done prior to a release so that those 
who browse to the site know that:
1 - the site is not an accurate source of information
or
2 - kqemu is no longer supported or maintained

Thanks
-Rick

>
> Regards,
>
> Anthony Liguori
>

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Paul Brook]

On Thursday 05 February 2009, Rick Vernam wrote:
> On Thursday 05 February 2009 8:26:04 am Anthony Liguori wrote:
> > kqemu is unsupported and unmaintained.
>
> Interesting.  When did it fall into that status?

IMHO It's pretty much always been that way.

> The Maintainers file shows Fabrice as the maintainer of kqemu.  I suppose
> that needs to be updated?
>
> I see Fabrice released 1.4.0pre1 on May 30th, 2008, although I never did
> see anything declaring it unsupported (I'm not suggesting it was never
> declared, just that I never saw any such declaration).
>
> Are there any plans to support it in the future?  This really is quite a
> shock to me, actually.  I know qemu has a wide range of uses - but for me
> and surely others, virtualization is a primary use.  To the best of my
> knowledge, kvm requires hardware support - where does this leave the class
> of users who need virtualization & don't have hardware virtualization
> support?  Are we no longer the a target audience of qemu?  If not, fine,
> but apparently a statement needs to be made...

You have the source, you're free to fork and maintain it yourself.

In practice Fabice is pretty much the only person who's ever done significant 
work on kqemu (except maybe some fairly minor host OS porting bits). There's 
never been a public source repository, so you get to use whatever random 
tarballs Fabrice leaves lying around. If those don't work, noone really 
cares.

Paul

Re: [Qemu-devel] Re: Cutting a new QEMU release

[René Rebe]

Paul Brook wrote:
> On Thursday 05 February 2009, Rick Vernam wrote:
>   
>> On Thursday 05 February 2009 8:26:04 am Anthony Liguori wrote:
>>     
>>> kqemu is unsupported and unmaintained.
>>>       
>> Interesting.  When did it fall into that status?
>>     
>
> IMHO It's pretty much always been that way.
>
>   
>> The Maintainers file shows Fabrice as the maintainer of kqemu.  I suppose
>> that needs to be updated?
>>
>> I see Fabrice released 1.4.0pre1 on May 30th, 2008, although I never did
>> see anything declaring it unsupported (I'm not suggesting it was never
>> declared, just that I never saw any such declaration).
>>
>> Are there any plans to support it in the future?  This really is quite a
>> shock to me, actually.  I know qemu has a wide range of uses - but for me
>> and surely others, virtualization is a primary use.  To the best of my
>> knowledge, kvm requires hardware support - where does this leave the class
>> of users who need virtualization & don't have hardware virtualization
>> support?  Are we no longer the a target audience of qemu?  If not, fine,
>> but apparently a statement needs to be made...
>>     
>
> You have the source, you're free to fork and maintain it yourself.
>
> In practice Fabice is pretty much the only person who's ever done significant 
> work on kqemu (except maybe some fairly minor host OS porting bits). There's 
> never been a public source repository, so you get to use whatever random 
> tarballs Fabrice leaves lying around. If those don't work, noone really 
> cares.
>   
I find this rather drastic. So far it appears to work pretty well. And given
the sheer amount of CPU sililcon without VT/SVM it looks to be worth
keeping working. Maybe just to pull it into the Qemu SVN?

Btw. anyone knows what Fabice is doing these days?

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

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Paul Brook]

> given the sheer amount of CPU sililcon without VT/SVM it looks to be worth
> keeping [kqemu] working. Maybe just to pull it into the Qemu SVN?

I'd rather not.  What you[1] really need to do is get it merged into upstream 
linux kernels.  There have been several threads about this previously, the 
short version is that it probably involves rewriting to use the kvm API.
You'll find that many developers (including myself) have extremely low 
tolerance for out of tree kernel modules[2].

Paul

[1] Or someone else who actually cares/is paid to care about kqemu.
[2] Obviously there's a bit of chicken and egg here. Upstream submission 
should at least be a fairly near-term goal.

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Daniel P. Berrange]

On Thu, Feb 05, 2009 at 05:36:22PM +0000, Paul Brook wrote:
> > given the sheer amount of CPU sililcon without VT/SVM it looks to be worth
> > keeping [kqemu] working. Maybe just to pull it into the Qemu SVN?
> 
> I'd rather not.  What you[1] really need to do is get it merged into upstream 
> linux kernels.  There have been several threads about this previously, the 
> short version is that it probably involves rewriting to use the kvm API.
> You'll find that many developers (including myself) have extremely low 
> tolerance for out of tree kernel modules[2].

More fundamentally, whether in or out of tree, someone needs to step
forward & commit to being an active long term maintainer for the code.
Having it in QEMU SVN without someone maintaining it won't help the
current situation, and nor will dumping it upstream without someone
maintaining it.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Ben Taylor]

On Thu, Feb 5, 2009 at 11:27 AM, Paul Brook <paul@codesourcery.com> wrote:
>
> In practice Fabice is pretty much the only person who's ever done significant
> work on kqemu (except maybe some fairly minor host OS porting bits). There's
> never been a public source repository, so you get to use whatever random
> tarballs Fabrice leaves lying around. If those don't work, noone really
> cares.

I've maintained tarballs for both 1.4.0 and 1.3.0 at the qemu project
on OpenSolaris.org, and just realized that I never put into the SVN repo
the mods I made to the 1.4.0 code.  I had tested it with Solaris SXCE
and Ubuntu 08.04.  If anyone shows some interest in testing, I'll import
the 1.4.0 into the SVN repo.  I believe that I picked up the minor
patches that were posted to the list to fix compilations on linux
with some various kernels.

Ben

Re: [Qemu-devel] Re: Cutting a new QEMU release

[René Rebe]

Ben Taylor wrote:
> On Thu, Feb 5, 2009 at 11:27 AM, Paul Brook <paul@codesourcery.com> wrote:
>   
>> In practice Fabice is pretty much the only person who's ever done significant
>> work on kqemu (except maybe some fairly minor host OS porting bits). There's
>> never been a public source repository, so you get to use whatever random
>> tarballs Fabrice leaves lying around. If those don't work, noone really
>> cares.
>>     
>
> I've maintained tarballs for both 1.4.0 and 1.3.0 at the qemu project
> on OpenSolaris.org, and just realized that I never put into the SVN repo
> the mods I made to the 1.4.0 code.  I had tested it with Solaris SXCE
> and Ubuntu 08.04.  If anyone shows some interest in testing, I'll import
> the 1.4.0 into the SVN repo.  I believe that I picked up the minor
> patches that were posted to the list to fix compilations on linux
> with some various kernels.
>   
Hm - kqemu-1.4.0pre1 builds for at least 2.6.28 and 2.6.26 for x86 and 
x86-64
on my side.

Anyway, could you post your modifications, some unsorted drop to my 
privately
is also welcome if you miss the time to sort it out.

Thanks,

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

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Anthony Liguori]

Ben Taylor wrote:
> On Thu, Feb 5, 2009 at 11:27 AM, Paul Brook <paul@codesourcery.com> wrote:
>   
>> In practice Fabice is pretty much the only person who's ever done significant
>> work on kqemu (except maybe some fairly minor host OS porting bits). There's
>> never been a public source repository, so you get to use whatever random
>> tarballs Fabrice leaves lying around. If those don't work, noone really
>> cares.
>>     
>
> I've maintained tarballs for both 1.4.0 and 1.3.0 at the qemu project
> on OpenSolaris.org, and just realized that I never put into the SVN repo
> the mods I made to the 1.4.0 code.  I had tested it with Solaris SXCE
> and Ubuntu 08.04.  If anyone shows some interest in testing, I'll import
> the 1.4.0 into the SVN repo.  I believe that I picked up the minor
> patches that were posted to the list to fix compilations on linux
> with some various kernels.
>   

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.

Regards,

Anthony Liguori

> Ben
>
>
>   

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Steve Fosdick]

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.

Regards,
Steve.

Re: [Qemu-devel] Re: Cutting a new QEMU release

[René Rebe]

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

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Anthony Liguori]

René Rebe wrote:
>
> Hi, 
>>
> 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.

I think you misunderstand.  Noone is claiming that kqemu is no longer 
being supported.  Quite rather, we're simply stating it's never been 
supported.

It started as a binary kernel module, impossible to support within the 
QEMU community.  While Fabrice has open sourced kqemu, it's never been 
included in QEMU.  It's not maintained by the current QEMU maintainers 
and not supported by the current QEMU maintainers.

It's essentially a separate project.

Regards,

Anthony Liguori

> 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,
>

Re: [Qemu-devel] Re: Cutting a new QEMU release

[René Rebe]

Anthony Liguori wrote:
> René Rebe wrote:
>>
>> Hi,
>>>
>> 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.
> 
> I think you misunderstand.  Noone is claiming that kqemu is no longer 
> being supported.  Quite rather, we're simply stating it's never been 
> supported.
> 
> It started as a binary kernel module, impossible to support within the 
> QEMU community.  While Fabrice has open sourced kqemu, it's never been 
> included in QEMU.  It's not maintained by the current QEMU maintainers 
> and not supported by the current QEMU maintainers.

I know about the history pretty well.

Btw. is Farbrice still actively working on Qemu related code these
days?

> It's essentially a separate project.

Well - depends. The user-space part always was in Qemu, but the
kernel module apparently is a little left aside. However, this
should not stop us from improving the situation instead of letting
it bitrott.

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

[Qemu-devel] Re: Cutting a new QEMU release

[Jamie Lokier]

Anthony Liguori wrote:
> >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.
> 
> I think you misunderstand.  Noone is claiming that kqemu is no longer 
> being supported.  Quite rather, we're simply stating it's never been 
> supported.
> 
> It started as a binary kernel module, impossible to support within the 
> QEMU community.  While Fabrice has open sourced kqemu, it's never been 
> included in QEMU.  It's not maintained by the current QEMU maintainers 
> and not supported by the current QEMU maintainers.
> 
> It's essentially a separate project.

Yes, it's unfortunate how its history worked out.  On the face of it,
it looks like Fabrice was hoping for someone to pay for it.  Maybe
they did.  I remember a vague murmur of an attempt to make an open
source replacement for kqemu when it was still binary-only; that
didn't go anywhere as far as I remember.

Anthony: If one or more maintainers were to step up, perhaps even
begin adapting the kqemu interface to kvm's, would you be interested
in folding it in the main qemu/kvm project as an official feature?

Straw poll: who here's interested in maintaining kqemu?

I have very little time, but plenty of x86 intimate knowledge and
kernel knowledge, and have used kqemu occasionally.  I can offer my
hand as "interested a bit, not by myself".

(Also, perhaps some of the Windows / other kqemu bits might be useful
in porting kvm to Windows.  Now that we have nested kvm, those of us
who never run a native Windows host can think about testing such a thing ;-)

-- Jamie

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Laurent Desnogues]

On Sat, Feb 7, 2009 at 5:49 PM, Jamie Lokier <jamie@shareable.org> wrote:
> I remember a vague murmur of an attempt to make an open
> source replacement for kqemu when it was still binary-only; that
> didn't go anywhere as far as I remember.

I think you're referring to Paul's qvm86.

http://savannah.nongnu.org/projects/qvm86


Laurent

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Anthony Liguori]

Jamie Lokier wrote:
> Anthony Liguori wrote:
>   
> Yes, it's unfortunate how its history worked out.  On the face of it,
> it looks like Fabrice was hoping for someone to pay for it.  Maybe
> they did.  I remember a vague murmur of an attempt to make an open
> source replacement for kqemu when it was still binary-only; that
> didn't go anywhere as far as I remember.
>
> Anthony: If one or more maintainers were to step up, perhaps even
> begin adapting the kqemu interface to kvm's, would you be interested
> in folding it in the main qemu/kvm project as an official feature?
>   

Actions speak louder than words.  All it takes is for someone to setup a 
tree somewhere with kqemu in it, and start working on it and merging 
patches.  Once that happens, we can discuss the long term future wrt KVM 
and QEMU.  Otherwise, it's just pontificating here.  Merging into Linux 
proper is going to be a lot of work.

I strongly suspect you won't see anyone step up.  From a developer 
perspective, it's a case of diminishing returns.  The more work you put 
into it, the less useful it is to people.  Every day that goes buy, the 
potential audience grows smaller.  Furthermore, the barrier to entry for 
someone to get a better solution is (i.e. KVM) is rather small.  Just 
buy a new CPU.

I think the only way it would prove useful to maintain is if some 
developer either has a deep desire to mess around with this kind of 
stuff or has a large customer base with pre-VT/SVM hardware that they 
wish to support.  So far, no such developer has proven to exist.  
Recall, even when kqemu was the only solution (but closed source), there 
wasn't really anyone interested/willing to maintain qvm86.

N.B. KVM and kqemu are not equal solutions.  Even at it's best, kqemu is 
going to be significantly slower than KVM in most cases.  When dealing 
with more modern CPUs (Barcelonas and Core i7s), the difference is going 
to be extremely high.

Regards,

Anthony Liguori

> Straw poll: who here's interested in maintaining kqemu?
>
> I have very little time, but plenty of x86 intimate knowledge and
> kernel knowledge, and have used kqemu occasionally.  I can offer my
> hand as "interested a bit, not by myself".
>
> (Also, perhaps some of the Windows / other kqemu bits might be useful
> in porting kvm to Windows.  Now that we have nested kvm, those of us
> who never run a native Windows host can think about testing such a thing ;-)
>
> -- Jamie
>
>
>   

Re: [Qemu-devel] Re: Cutting a new QEMU release

[René Rebe]

René Rebe wrote:

> 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).

Ok, those segfaults where due to an old non-NPTL glibc and the __thread
support being nonfunctional in this combination used in the kvm tree :-)

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

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Jamie Lokier]

Steve Fosdick wrote:
> 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.

In a couple of brief threads before, it was made fairly clear that kvm
developers believe CPUs without the virtualisation feature are
essentially obsolete, not just non-current.

I sympathise with that view, now that my laptop has the feature :-)

But it does seem harsh, a rather sudden cut-off point as it was only a
few years ago that the virtualisation feature was not common, and it's
still not available on all x86s.

-- Jamie

Re: [Qemu-devel] Re: Cutting a new QEMU release

[C.W. Betts]

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


On Feb 5, 2009, at 12:03 PM, Anthony Liguori wrote:

> Ben Taylor wrote:
>> On Thu, Feb 5, 2009 at 11:27 AM, Paul Brook <paul@codesourcery.com>  
>> wrote:
>>
>>> In practice Fabice is pretty much the only person who's ever done  
>>> significant
>>> work on kqemu (except maybe some fairly minor host OS porting  
>>> bits). There's
>>> never been a public source repository, so you get to use whatever  
>>> random
>>> tarballs Fabrice leaves lying around. If those don't work, noone  
>>> really
>>> cares.
>>>
>>
>> I've maintained tarballs for both 1.4.0 and 1.3.0 at the qemu project
>> on OpenSolaris.org, and just realized that I never put into the SVN  
>> repo
>> the mods I made to the 1.4.0 code.  I had tested it with Solaris SXCE
>> and Ubuntu 08.04.  If anyone shows some interest in testing, I'll  
>> import
>> the 1.4.0 into the SVN repo.  I believe that I picked up the minor
>> patches that were posted to the list to fix compilations on linux
>> with some various kernels.
>>
>
> 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.
>
The only thing that prevents kvm being used in Windows or Darwin/OS X  
is that it depends too heavily on the Linux Kernel.  Kqemu, on the  
other hand, has been ported to Windows, and someone tried to do a  
Darwin port.

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

Re: [Qemu-devel] Re: Cutting a new QEMU release

[C.W. Betts]

Okay, what is keeping Qemu from releasing a new version?  I say we  
release a release candidate, wait for people to find the bugs (two or  
three weeks), then release a new "official" version.

Re: [Qemu-devel] Re: Cutting a new QEMU release

[René Rebe]

C.W. Betts wrote:
> Okay, what is keeping Qemu from releasing a new version?  I say we 
> release a release candidate, wait for people to find the bugs (two or 
> three weeks), then release a new "official" version.

I would prefer a release "schedule" like kvm: every other month - often
and quickly.

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

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Andreas Färber]

Am 05.02.2009 um 18:51 schrieb Ben Taylor:

> On Thu, Feb 5, 2009 at 11:27 AM, Paul Brook <paul@codesourcery.com>  
> wrote:
>>
>> In practice Fabice is pretty much the only person who's ever done  
>> significant
>> work on kqemu (except maybe some fairly minor host OS porting  
>> bits). There's
>> never been a public source repository, so you get to use whatever  
>> random
>> tarballs Fabrice leaves lying around. If those don't work, noone  
>> really
>> cares.
>
> I've maintained tarballs for both 1.4.0 and 1.3.0 at the qemu project
> on OpenSolaris.org, and just realized that I never put into the SVN  
> repo
> the mods I made to the 1.4.0 code.  I had tested it with Solaris SXCE
> and Ubuntu 08.04.  If anyone shows some interest in testing, I'll  
> import
> the 1.4.0 into the SVN repo.  I believe that I picked up the minor
> patches that were posted to the list to fix compilations on linux
> with some various kernels.

I have happily used kqemu 1.4 on OpenSolaris for several months  
without problems, running Linux in sparc-softmmu and Haiku/BeOS in  
i386-softmmu.

I did have to tweak the Makefile a little for kqemu to link on  
OpenSolaris/amd64, I believe. Possibly by replacing ld with path/to/ 
amd64/ld.

There has been no rumor of any KVM port to Solaris. Linux kernel  
integration cannot be the only criteria.
It used to work in early December - could we set up a Git repo for  
Fabrice's official tarball? Then we could apply the OpenSolaris.org  
changes on a branch and play with our own Git forks to keep it working  
as long as there is no alternative. Asking for maintainers of  
unversioned software seems doomed to fail.

Andreas

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Jamie Lokier]

Andreas Färber wrote:
> There has been no rumor of any KVM port to Solaris. Linux kernel  
> integration cannot be the only criteria.

Does Solaris not have their own equivalent to KVM, for running VMs?

-- Jamie

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Andreas Färber]

Am 15.02.2009 um 16:44 schrieb Jamie Lokier:

> Andreas Färber wrote:
>> There has been no rumor of any KVM port to Solaris. Linux kernel
>> integration cannot be the only criteria.
>
> Does Solaris not have their own equivalent to KVM, for running VMs?

Sun has xVM (based on Xen) with virt-manager UI. But it didn't run,  
e.g., Haiku and doesn't help with non-native (sparc-/ppc-softmmu)  
emulation either.
I'm not looking for a virtualization technology on Solaris but for a  
platform suited for my uses of QEMU emulation (and that box was pretty  
fast :).

However unsupported, QEMU+kqemu on OpenSolaris/amd64 is much faster  
than unaccelerated QEMU on OSX/ppc!

And trying to set up any KVM guest in Fedora was a pain. Haven't tried  
the new KVM integration in QEMU trunk yet. Maybe kqemu really has a  
bad kernel interface, but it's simple to set up and fits the needs of  
my use cases:

- booting existing hard disk images without one-time booting from an  
ISO image first (virt-manager seems to require the latter)
- storing the image files anywhere I like, including my home dir  
(SELinux messes with that on Fedora 10)
- starting the VM from an unpriviledged user, preferably from a shell  
script

Andreas

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Anthony Liguori]

Andreas Färber wrote:
>
> Am 05.02.2009 um 18:51 schrieb Ben Taylor:
>
>> On Thu, Feb 5, 2009 at 11:27 AM, Paul Brook <paul@codesourcery.com> 
>> wrote:
>>>
>>> In practice Fabice is pretty much the only person who's ever done 
>>> significant
>>> work on kqemu (except maybe some fairly minor host OS porting bits). 
>>> There's
>>> never been a public source repository, so you get to use whatever 
>>> random
>>> tarballs Fabrice leaves lying around. If those don't work, noone really
>>> cares.
>>
>> I've maintained tarballs for both 1.4.0 and 1.3.0 at the qemu project
>> on OpenSolaris.org, and just realized that I never put into the SVN repo
>> the mods I made to the 1.4.0 code.  I had tested it with Solaris SXCE
>> and Ubuntu 08.04.  If anyone shows some interest in testing, I'll import
>> the 1.4.0 into the SVN repo.  I believe that I picked up the minor
>> patches that were posted to the list to fix compilations on linux
>> with some various kernels.
>
> I have happily used kqemu 1.4 on OpenSolaris for several months 
> without problems, running Linux in sparc-softmmu and Haiku/BeOS in 
> i386-softmmu.
>
> I did have to tweak the Makefile a little for kqemu to link on 
> OpenSolaris/amd64, I believe. Possibly by replacing ld with 
> path/to/amd64/ld.
>
> There has been no rumor of any KVM port to Solaris. Linux kernel 
> integration cannot be the only criteria.
> It used to work in early December - could we set up a Git repo for 
> Fabrice's official tarball? Then we could apply the OpenSolaris.org 
> changes on a branch and play with our own Git forks to keep it working 
> as long as there is no alternative. Asking for maintainers of 
> unversioned software seems doomed to fail.

Set up a repository somewhere.  You don't need anyone's permission for that.

Savannah isn't a great place for hosting.  You can only have one git 
repo per project.  I'd suggest something like github or repo.or.cz.

Regards,

Anthony Liguori

>
> Andreas
>
>
>

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Andreas Färber]

Am 15.02.2009 um 19:17 schrieb Anthony Liguori:

> Andreas Färber wrote:
>> [kqemu] used to work in early December - could we set up a Git repo  
>> for Fabrice's official tarball? Then we could apply the  
>> OpenSolaris.org changes on a branch and play with our own Git forks  
>> to keep it working as long as there is no alternative. Asking for  
>> maintainers of unversioned software seems doomed to fail.
>
> Set up a repository somewhere.  You don't need anyone's permission  
> for that.

I just did: http://repo.or.cz/w/kqemu.git

Andreas

Re: [Qemu-devel] Re: Cutting a new QEMU release

[René Rebe]

Hi,

Anthony Liguori wrote:
> Steve Fosdick wrote:
>> Given the talk of a new release I though I'd try the latest qemu from
>> SVN.  At the moment I am being hampered by kqemu-1.4.0pre1 not compiling
>> though:
>>
>>   CC [M]  /usr/src/kqemu-1.4.0pre1/kqemu-linux.o
>> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c: In function
>> ‘kqemu_lock_user_page’:
>> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:81: error: dereferencing pointer
>> to incomplete type
>> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c: In function ‘kqemu_schedule’:
>> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:194: error: implicit declaration
>> of function ‘need_resched’
>> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:195: error: implicit declaration
>> of function ‘schedule’
>> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:197: error: implicit declaration
>> of function ‘signal_pending’
>> make[2]: *** [/usr/src/kqemu-1.4.0pre1/kqemu-linux.o] Error 1
>>
>> This is with kernel 2.6.28.2. kqemu-1.3.0pre11 seems to compile OK with
>> the kernel.  Any ideas?
>>   
>
> kqemu is unsupported and unmaintained.
Ouhm. Why's that? Give that the vast majority of CPUs in use still don't
have hardware virtualization, ...

That said kqemu builds for me and works for me.

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

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Stefan Weil]

Anthony Liguori schrieb:
>
> kqemu is unsupported and unmaintained.
>
> Regards,
>
> Anthony Liguori
>

The kvm kernel module could be a good replacement for kqemu
for those running linux on new cpus.

It does not play this role in current linux distributions because
you will need newer versions of kvm which are sometimes
difficult to compile.

It will never play this role for those running "old" cpus.

And it will never play this role on Windows (or is there a kvm
for Windows?). I am surprised that nobody mentions this part
in the discussion.

So even if kqemu is unmaintained, the Qemu developers
should at least maintain the interface.

I'd prefer to have a svn tree with kqemu beside qemu.
Then patches could be sent, and maybe some day there could
be a maintainer, too.

Integration of code from virtualbox could be a way to replace
kqemu, but I don't see this coming in the near future.

Regards
Stefan Weil

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Anthony Liguori]

Stefan Weil wrote:
> The kvm kernel module could be a good replacement for kqemu
> for those running linux on new cpus.
>
> It does not play this role in current linux distributions because
> you will need newer versions of kvm which are sometimes
> difficult to compile.
>
> It will never play this role for those running "old" cpus.
>
> And it will never play this role on Windows (or is there a kvm
> for Windows?). I am surprised that nobody mentions this part
> in the discussion.
>
> So even if kqemu is unmaintained, the Qemu developers
> should at least maintain the interface.
>
> I'd prefer to have a svn tree with kqemu beside qemu.
> Then patches could be sent, and maybe some day there could
> be a maintainer, too.
>   

Nothing is stopping anyone from taking kqemu and setting up a SVN repo 
somewhere.  That's the beauty of the GPL.

Regards,

Anthony Liguori

> Integration of code from virtualbox could be a way to replace
> kqemu, but I don't see this coming in the near future.
>
> Regards
> Stefan Weil
>
>
>
>   

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Jamie Lokier]

Stefan Weil wrote:
> The kvm kernel module could be a good replacement for kqemu
> for those running linux on new cpus.

It's not yet, though.  kvm doesn't run 16-bit code properly.
I use kqemu to run older OSes, and kvm to run current ones.

I like the idea of a "kvm-soft", which is basically kqemu with a kvm
interface.  It would need a few extensions on the kvm interface, of
course.

Another potential use for _part_ of kqemu, or kvm-soft, is emulating
other CPUs with host kernel support for the memory map, instead of
full software TLB.  That might be a performance accelerator for
emulation, for some combinations of host and target CPUs where it's
feasible to map the memory in that way.

If kqemu were evolved into an accelerator for cross-CPU emulation in
that way, then its current use as an x86-on-x86 accelerator would just
be a special case of that.

-- Jamie

[Qemu-devel] Re: Cutting a new QEMU release

[Jan Kiszka]

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

Jamie Lokier wrote:
> Stefan Weil wrote:
>> The kvm kernel module could be a good replacement for kqemu
>> for those running linux on new cpus.
> 
> It's not yet, though.  kvm doesn't run 16-bit code properly.

You mean real mode, I guess. I think there are still a few holes in the
emulator that may bite you on certain DOSes or with some fancy boot
loaders. But 16-bit protected mode runs as fine as 32 or 64 bit for
quite a while now.

> I use kqemu to run older OSes, and kvm to run current ones.

I haven't found much code that caused troubles to kvm, but a lot that
broke kqemu - YMMV.

> 
> I like the idea of a "kvm-soft", which is basically kqemu with a kvm
> interface.  It would need a few extensions on the kvm interface, of
> course.
> 
> Another potential use for _part_ of kqemu, or kvm-soft, is emulating
> other CPUs with host kernel support for the memory map, instead of
> full software TLB.  That might be a performance accelerator for
> emulation, for some combinations of host and target CPUs where it's
> feasible to map the memory in that way.
> 
> If kqemu were evolved into an accelerator for cross-CPU emulation in
> that way, then its current use as an x86-on-x86 accelerator would just
> be a special case of that.

Most of kqemu's code base deals with / works around unvirtualizable x86
cruft. Memory management, page table handling is only a small subset.
And that part is focused on running guest code under the control of the
monitor, not in the TCG user space environment. So even if there is
something a kernel part could contribute to accelerate TCG execution,
I'm not sure that there will be a high re-use of kqemu's infrastructure
- or even kvm's.

You also should be aware of the fact the kqemu's x86 virtualization is
fairly fragile, only working for OSes like Linux and Windows, and even
there not always reliably (I've seen Linux kernels crashing). We are
evaluating alternative workarounds for these issues, but they will come
with their own limitations. Either they are too costly to implement
(binary translation) given the remaining lifetime of kqemu, or they
cause problems with self-checking guests (patch in traps & emulate). And
both will need special user space support beyond current kqemu's or
kvm's need. Depending on the outcome (for the picky customer OS), we may
be able to contribute to a properly maintained kqemu tree (or better:
kvm-soft). But this is yet open.

Jan


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

Re: [Qemu-devel] Re: Cutting a new QEMU release

[Rick Vernam]

On Thursday 05 February 2009 3:13:14 am Steve Fosdick wrote:
> Given the talk of a new release I though I'd try the latest qemu from
> SVN.  At the moment I am being hampered by kqemu-1.4.0pre1 not compiling
> though:
>
>   CC [M]  /usr/src/kqemu-1.4.0pre1/kqemu-linux.o
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c: In function
> ‘kqemu_lock_user_page’:
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:81: error: dereferencing pointer
> to incomplete type
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c: In function ‘kqemu_schedule’:
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:194: error: implicit declaration
> of function ‘need_resched’
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:195: error: implicit declaration
> of function ‘schedule’
> /usr/src/kqemu-1.4.0pre1/kqemu-linux.c:197: error: implicit declaration
> of function ‘signal_pending’
> make[2]: *** [/usr/src/kqemu-1.4.0pre1/kqemu-linux.o] Error 1
>
> This is with kernel 2.6.28.2. kqemu-1.3.0pre11 seems to compile OK with
> the kernel.  Any ideas?
I, and another, posted about this some time ago.  The solution is a particular 
#include somewhere, which I don't recall off the top of my head.
It's in the list somewhere, if you look hard enough.

>
> Regards,
> Steve.

[Qemu-devel] Cutting a new QEMU release

[Anthony Liguori]

What do people think?  TCG seems to be in a good place.  We've got 
virtio, KVM, live migration, tons of new devices, bsd-user, etc.

We could decide to cut one by the end of the month.  I'm already doing 
some test work in QEMU so I can follow up with some more detailed notes 
about what is working and what isn't working.  That gives us some time 
to decide if there's anything we need to fix before a release.

Regards,

Anthony Liguori

Re: [Qemu-devel] Cutting a new QEMU release

[Aurelien Jarno]

On Tue, Feb 03, 2009 at 02:48:22PM -0600, Anthony Liguori wrote:
> What do people think?  TCG seems to be in a good place.  We've got  
> virtio, KVM, live migration, tons of new devices, bsd-user, etc.
>
> We could decide to cut one by the end of the month.  I'm already doing  
> some test work in QEMU so I can follow up with some more detailed notes  
> about what is working and what isn't working.  That gives us some time  
> to decide if there's anything we need to fix before a release.
>

That's a really good idea.

I would like to see the switch of the remaining PowerPC machine from
OpenHackware to OpenBIOS. We don't have the sources of the current
ppc_rom.bin binary, and I don't feel comfortable making a release with
it. We probably have the sources of an older version.

This at least concerned ppc_chrp.c (ppc_prep.c could probably simply
be dropped).

I have no idea about how long it would take.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Cutting a new QEMU release

[Tristan Gingold]

On Feb 4, 2009, at 3:50 PM, Aurelien Jarno wrote:
>
> This at least concerned ppc_chrp.c (ppc_prep.c could probably simply
> be dropped).

Please, don't drop ppc_prep.c.  Even if it is not supported by  
OpenBios I know several uses of prep
with direct images.

Tristan.

Re: [Qemu-devel] Cutting a new QEMU release

[Lennart Sorensen]

On Wed, Feb 04, 2009 at 04:23:10PM +0100, Tristan Gingold wrote:
> Please, don't drop ppc_prep.c.  Even if it is not supported by  
> OpenBios I know several uses of prep
> with direct images.

Who still support it?

The linux kernel seems to have thrown away the prep support code as of
2.6.27.

-- 
Len Sorensen

Re: [Qemu-devel] Cutting a new QEMU release

[Tristan Gingold]

On Feb 4, 2009, at 4:43 PM, Lennart Sorensen wrote:

> On Wed, Feb 04, 2009 at 04:23:10PM +0100, Tristan Gingold wrote:
>> Please, don't drop ppc_prep.c.  Even if it is not supported by
>> OpenBios I know several uses of prep
>> with direct images.
>
> Who still support it?

I know at least one non-free OS that runs on prep.
We also create raw programs that runs on prep (yes we could switch to  
chrp)

> The linux kernel seems to have thrown away the prep support code as of
> 2.6.27.

Yes, but the world is not only linux 2.6.27+ :-)

[Qemu-devel] Re: Cutting a new QEMU release

[Consul]

> 
> Yes, but the world is not only linux 2.6.27+ :-)
> 

Of course not. All the world's a VAX!