[arch-dev-public] KVM & Paravirtualization

Alexander Baldeck

3 Jun 2007 3 Jun '07

10:47 a.m.

Hey all, some of you may have noticed that we have a couple of feature requests on flyspray [1] [2] regarding a new KVM and paravirtualization. I've been messing with KVM on Linuxtag. So far it works well but there's a few issues with it: 1) makes no sense to port to non-x86_64 - i686 has kqemu - the kqemu on x86_64 is pretty much useless btw - I have never heard of a 32bit CPU that actually supports this - correct me if I'm wrong 2) it comes with a modified version of Qemu that only provides qemu-system-$CARCH and thus conflicts with qemu itself - merge with qemu package? - strip qemu-system-$CARCH off of qemu package? 3) KVM modules in our kernel26 are very outdated and should be removed in favor of the ones provided by the KVM source tarball 4) split KVM into kvm-qemu & kvm-modules? I have not yet tried to enable options like suggested in [2] yet but will do so soon. What do you think? Cheers, -H [1] http://bugs.archlinux.org/task/7331 [2] http://bugs.archlinux.org/task/7337

Show replies by date

Roman Kyrylych

3 Jun 3 Jun

11:10 a.m.

2007/6/3, Alexander Baldeck :

...

Hey all,

some of you may have noticed that we have a couple of feature requests on flyspray [1] [2] regarding a new KVM and paravirtualization. I've been messing with KVM on Linuxtag. So far it works well but there's a few issues with it:

1) makes no sense to port to non-x86_64 - i686 has kqemu - the kqemu on x86_64 is pretty much useless btw - I have never heard of a 32bit CPU that actually supports this - correct me if I'm wrong

What if user has Core 2 Duo or Athlon 64 for AM2, but runs Arch i686 on it? I'm sure there are enought users.

...

2) it comes with a modified version of Qemu that only provides qemu-system-$CARCH and thus conflicts with qemu itself - merge with qemu package? - strip qemu-system-$CARCH off of qemu package?

I think merge would be nice, if it's not hard to implement, and won't break qemu's work with non-paravirualized machines. There are plans to merge KVM functionality into mainline qemu AFAIR.

...

3) KVM modules in our kernel26 are very outdated and should be removed in favor of the ones provided by the KVM source tarball

Well, in 2.6.22 it will be updated in kernel, but because new KVM versions are developed faster than kernel is released - I agree it will be better to have it separated.

...

4) split KVM into kvm-qemu & kvm-modules?

I have not yet tried to enable options like suggested in [2] yet but will do so soon.

What do you think?

We cannot enable it for 2.6.21 kernel because external non-free drivers will be broken. But the good news are that in 2.6.22 paravirt_ops is no longer a GPL-only export! :-)

...

[1] http://bugs.archlinux.org/task/7331 [2] http://bugs.archlinux.org/task/7337

-- Roman Kyrylych (Роман Кирилич)

Alexander Baldeck

1:12 p.m.

Roman Kyrylych wrote:

...

What if user has Core 2 Duo or Athlon 64 for AM2, but runs Arch i686 on it? I'm sure there are enought users.

The thing is that - assuming it is possible - if you run a i686 guest in kvm-qemu on a x86_64 host, the guest does not need KVM as well.

...

...
2) it comes with a modified version of Qemu that only provides qemu-system-$CARCH and thus conflicts with qemu itself - merge with qemu package? - strip qemu-system-$CARCH off of qemu package?

I think merge would be nice, if it's not hard to implement, and won't break qemu's work with non-paravirualized machines. There are plans to merge KVM functionality into mainline qemu AFAIR.

If it will be integrated into the qemu mainline we should wait for that to happen, no?

...

Well, in 2.6.22 it will be updated in kernel, but because new KVM versions are developed faster than kernel is released - I agree it will be better to have it separated.

Exactly, we could although assume that the modules provided by the kernel as the stable version. I can't tell since I haven't built and tested kvm-17, which would match our current kernel26.

...

We cannot enable it for 2.6.21 kernel because external non-free drivers will be broken. But the good news are that in 2.6.22 paravirt_ops is no longer a GPL-only export! :-)

I haven't even seen the option as mentioned in [1] in the current release. Where did you get the info from? Maybe Debian patched it in? Cheers, -Z [1] http://bugs.archlinux.org/task/7337

Jan de Groot

6:42 p.m.

On Sun, 2007-06-03 at 14:10 +0300, Roman Kyrylych wrote:

...

2007/6/3, Alexander Baldeck :

...
Hey all,

some of you may have noticed that we have a couple of feature requests on flyspray [1] [2] regarding a new KVM and paravirtualization. I've been messing with KVM on Linuxtag. So far it works well but there's a few issues with it:

1) makes no sense to port to non-x86_64 - i686 has kqemu - the kqemu on x86_64 is pretty much useless btw - I have never heard of a 32bit CPU that actually supports this - correct me if I'm wrong

What if user has Core 2 Duo or Athlon 64 for AM2, but runs Arch i686 on it? I'm sure there are enought users.

I happen to have such a CPU which runs i686. KVM is a requirement for qemu on x86_64 to be useful, on i686 we can choose between KVM and kqemu.

...

...
2) it comes with a modified version of Qemu that only provides qemu-system-$CARCH and thus conflicts with qemu itself - merge with qemu package? - strip qemu-system-$CARCH off of qemu package?

I think merge would be nice, if it's not hard to implement, and won't break qemu's work with non-paravirualized machines. There are plans to merge KVM functionality into mainline qemu AFAIR.

Just take KVM qemu and change the flags to build with --enable-kqemu, I tried this and qemu works with both KVM and kqemu in that way.

...

...
3) KVM modules in our kernel26 are very outdated and should be removed in favor of the ones provided by the KVM source tarball

Well, in 2.6.22 it will be updated in kernel, but because new KVM versions are developed faster than kernel is released - I agree it will be better to have it separated.

Either package it as standalone or update the kernel with the new version. Both should be fine, though packaging it standalone means [4].

...

...
4) split KVM into kvm-qemu & kvm-modules?

James Rayner

12:28 p.m.

On Sun, Jun 03, 2007 at 12:47:41PM +0200, Alexander Baldeck wrote:

...

Hey all,

some of you may have noticed that we have a couple of feature requests on flyspray [1] [2] regarding a new KVM and paravirtualization. I've been messing with KVM on Linuxtag. So far it works well but there's a few issues with it:

1) makes no sense to port to non-x86_64 - i686 has kqemu - the kqemu on x86_64 is pretty much useless btw - I have never heard of a 32bit CPU that actually supports this - correct me if I'm wrong

what about a capable 64bit processor running a 32 bit distro? Like the core 2 duos, pentium D 9x0..?

...

2) it comes with a modified version of Qemu that only provides qemu-system-$CARCH and thus conflicts with qemu itself - merge with qemu package? - strip qemu-system-$CARCH off of qemu package?

could also rename the binary, otherwise, if you're using kvm, then you probably wont mind if you dont have stock qemu, so a conflicts should be fine?

...

3) KVM modules in our kernel26 are very outdated and should be removed in favor of the ones provided by the KVM source tarball

or would it be better to patch the kernel with the new one?

...

4) split KVM into kvm-qemu & kvm-modules?

definitely split the modules off if they must be seperated from the kernel. James

Dale Blount

12:58 p.m.

On Sun, 2007-06-03 at 22:28 +1000, James Rayner wrote:

...

On Sun, Jun 03, 2007 at 12:47:41PM +0200, Alexander Baldeck wrote:

...
Hey all,

some of you may have noticed that we have a couple of feature requests on flyspray [1] [2] regarding a new KVM and paravirtualization. I've been messing with KVM on Linuxtag. So far it works well but there's a few issues with it:

1) makes no sense to port to non-x86_64 - i686 has kqemu - the kqemu on x86_64 is pretty much useless btw - I have never heard of a 32bit CPU that actually supports this - correct me if I'm wrong

what about a capable 64bit processor running a 32 bit distro? Like the core 2 duos, pentium D 9x0..?

Count me in here... This is what I was planning on doing on my core 2 duo server when I get around to it.

...

...
2) it comes with a modified version of Qemu that only provides qemu-system-$CARCH and thus conflicts with qemu itself - merge with qemu package? - strip qemu-system-$CARCH off of qemu package?

could also rename the binary, otherwise, if you're using kvm, then you probably wont mind if you dont have stock qemu, so a conflicts should be fine?

I'd say it'd be fine to conflict. You probably won't use both on the same system.

...

...
3) KVM modules in our kernel26 are very outdated and should be removed in favor of the ones provided by the KVM source tarball

or would it be better to patch the kernel with the new one?

...
4) split KVM into kvm-qemu & kvm-modules?

definitely split the modules off if they must be seperated from the kernel.

Agreed. Dale

Jason Chu

6:42 p.m.

On Sun, Jun 03, 2007 at 12:47:41PM +0200, Alexander Baldeck wrote:

...

Hey all,

some of you may have noticed that we have a couple of feature requests on flyspray [1] [2] regarding a new KVM and paravirtualization. I've been messing with KVM on Linuxtag. So far it works well but there's a few issues with it:

1) makes no sense to port to non-x86_64 - i686 has kqemu - the kqemu on x86_64 is pretty much useless btw - I have never heard of a 32bit CPU that actually supports this - correct me if I'm wrong

I'm pretty sure my Core Duo has it. It's only 32bit.

...

2) it comes with a modified version of Qemu that only provides qemu-system-$CARCH and thus conflicts with qemu itself - merge with qemu package? - strip qemu-system-$CARCH off of qemu package?

What about the way the kvm package in AUR works? It creates a qemu-kvm and puts all the binaries in a different directory (so qemu-system-$CARCH doesn't conflict).

...

3) KVM modules in our kernel26 are very outdated and should be removed in favor of the ones provided by the KVM source tarball

I agree.

...

4) split KVM into kvm-qemu & kvm-modules?

That's usually how we do it...

...

I have not yet tried to enable options like suggested in [2] yet but will do so soon.

What do you think?

Cheers,

-H

[1] http://bugs.archlinux.org/task/7331 [2] http://bugs.archlinux.org/task/7337

I also disagree with some of the sentiment that you only need qemu or kvm. I have vmware, qemu, and kvm installed right now. I have them all serving different purposes and each of them breaks for one reason or another as updates happen :P Jason

6173

Age (days ago)

6173

Last active (days ago)

List overview

Download

6 comments

6 participants

participants (6)

Alexander Baldeck
Dale Blount
James Rayner
Jan de Groot
Jason Chu
Roman Kyrylych