Re: kvm or qemu-kvm?

Ross Boylan wrote:
> http://www.linux-kvm.org/page/HOWTO1 says to build kvm I should get the
> latest kvm-release.tar.gz.
> 
> http://www.linux-kvm.org/page/Downloads says "If you want to use the
> latest version of KVM kernel modules and supporting userspace, you can
> download the latest version from
> http://sourceforge.net/project/showfiles.php?group_id=180599."
> That page shows the latest version is qemu-kvm-0.11.0.tar.gz.
> 
> The most recent kvm-release.tar.gz appears to be for kvm-88.
> 
> So which file should I start from?

If you don't know what you want, you want qemu-kvm, which is based off a 
stable release of qemu.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

buildbot failure in qemu-kvm on disable_kvm_x86_64_out_of_tree

The Buildbot has detected a new failure of disable_kvm_x86_64_out_of_tree on qemu-kvm.
Full details are available at:
 http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_out_of_tree/builds/29

Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/

Buildslave for this Build: b1_qemu_kvm_1

Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

buildbot failure in qemu-kvm on disable_kvm_x86_64_debian_5_0

The Buildbot has detected a new failure of disable_kvm_x86_64_debian_5_0 on qemu-kvm.
Full details are available at:
 http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_debian_5_0/builds/80

Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/

Buildslave for this Build: b1_qemu_kvm_1

Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Fix warning in sync

Patch is self-explanatory

commit 071a800cd07c2b9d13c7909aa99016d89a814ae6
Author: Zachary Amsden <zamsden <at> redhat.com>
Date:   Wed Sep 30 17:03:16 2009 -1000

    Remove warning due to kvm_mmu_notifier_change_pte being static

    Signed-off-by: Zachary Amsden <zamsden <at> redhat.com>

diff --git a/sync b/sync
index b09f629..0bbd488 100755
--- a/sync
+++ b/sync
 <at>  <at>  -97,6 +97,9  <at>  <at>  def __hack(data):
             line = '#include <asm/types.h>'
         if match(r'\t\.change_pte.*kvm_mmu_notifier_change_pte,'):
             line = '#ifdef MMU_NOTIFIER_HAS_CHANGE_PTE\n' + line + '\n#endif'
+        if match(r'static void kvm_mmu_notifier_change_pte'):
+            line = sub(r'static ', '', line)
+            line = '#ifdef MMU_NOTIFIER_HAS_CHANGE_PTE\n' + 'static\n' + '#endif\n' + line
         line = sub(r'\bhrtimer_init\b', 'hrtimer_init_p', line)
         line = sub(r'\bhrtimer_start\b', 'hrtimer_start_p', line)
         line = sub(r'\bhrtimer_cancel\b', 'hrtimer_cancel_p', line)

Re: buildbot failure in qemu-kvm on disable_kvm_x86_64_debian_5_0

On Thursday 01 October 2009 04:05:40 am qemu-kvm <at> buildbot.b1-systems.de wrote:
> The Buildbot has detected a new failure of disable_kvm_x86_64_debian_5_0 on
>  qemu-kvm. Full details are available at:
>  http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_debian_
> 5_0/builds/80
> 
> Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
> 
> Buildslave for this Build: b1_qemu_kvm_1
> 
> Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered
>  this build Build Source Stamp: [branch master] HEAD
> Blamelist:
> 
> BUILD FAILED: failed compile

Please ignore buildbot failure disable_kvm_x86_64_debian_5_0 (#80) and  
disable_kvm_x86_64_out_of_tree (#29)

Two nightly builds got scheduled at the same time (disable_kvm and out-of-
tree_disable_kvm) for the same buildslave ... which caused memory preasure in 
the tiny buildslave VM. Will change that: out-of-tree should get (nightly) 
build tested an hour later or so ... to avoid two builds at the same time.

Best Regards,
Daniel

--

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg

Re: [Qemu-devel] Re: [PATCH 1/1] qemu-kvm: virtio-net: Re-instate GSO code removed upstream

On Wed, 2009-09-30 at 21:15 +0200, Gerd Hoffmann wrote:
> On 09/30/09 15:59, Mark McLoughlin wrote:
> > I'm planning on adding -hostnet and -nic arguments, which would not use
> > vlans by default but rather connect the nic directly to the host side.
> 
> No new -nic argument please.  We should just finalize the qdev-ifycation 
> of the nic drivers, then you'll do either
> 
>    -device e1000,vlan=<nr>
> 
> or
> 
>    -device e1000,hostnet=<name>
> 
> and be done with it.

Yeah, that makes sense.

Cheers,
Mark.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Q: Stopped VM still using host cpu CPU ?

Hi,

we are running some stopped (sending "stop" via kvm-monitor socket) 
vm's on our system. My intention was to pause (stop) the vm's and
unpause (cont) them on demand (very fast, without time delay, within 2
seconds ..).

After 'stop'ing, the vm's still using CPU-load, like the "top" will
tell:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

25983 root      20   0  495m 407m 1876 R  8.9  2.5 228:09.15
qemu-system-x86                                          
25523 root      20   0  495m 2040 1868 S  7.9  0.0   2700:16
qemu-system-x86                                          
19738 root      20   0 1139m  40m 1876 R  7.3  0.3   2501:57
qemu-system-x86                                          
32521 root      20   0  495m 407m 1876 S  6.9  2.5 136:23.23
qemu-system-x86                                          
21773 root      20   0  495m 407m 1876 S  5.6  2.5 575:01.44
qemu-system-x86                                          
 6720 root      20   0 2168m 2.0g 1876 R  4.6 12.9 524:55.70
qemu-system-x86                                          
 6819 root      20   0 2168m 2.0g 1876 S  4.6 12.9 489:24.24
qemu-system-x86                                          
12752 root      20   0  495m 407m 1876 S  4.6  2.5   0:44.57
qemu-system-x86                                          
22803 root      20   0 1139m 211m 1868 S  4.0  1.3   1217:21
qemu-system-x86                                          

RE: Q: Stopped VM still using host cpu CPU ?

One more,

> So, how can I prevent the paused/stopped VM's to use my CPU from
> the hostsystem ? Is there a way to handle this ?

If i send a signal STOP/CONT (kill -STOP <pid> or kill -CONT <pid>)
to the KVM-process, it looks like the kvm does not (sure  use
any host CPU usage.

- Are there some side effects using this approach ? 
 (e.g. with networking, ...)

- And, why is there a way to send STOP/CONT via socket to KVM-process ?
Why
  not using the sending-signal-apporch ?

best regards
Danny

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/24] compatfd is included before, and it is compiled unconditionally

Christoph Hellwig <hch <at> infradead.org> wrote:
> On Tue, Sep 22, 2009 at 03:25:13PM +0200, Juan Quintela wrote:
>> Christoph Hellwig <hch <at> infradead.org> wrote:
>> > Btw, what's the state of getting compatfd upstream?  It's a pretty
>> > annoying difference between qemu upstream and qemu-kvm.
>> 
>> I haven't tried.  I can try to send a patch.  Do you have any use case
>> that will help the cause?
>
> Well, the eventfd compat is used in the thread pool AIO code.  I don't
> know what difference it makes, but I really hate this code beeing
> different in both trees.  I want to see compatfd used either in both or
> none.

Discused with Anthony about it.  signalfd is complicated for qemu
upstream (too difficult to use properly), and eventfd ...  The current
eventfd emulation is worse than the pipe code that it substitutes.

His suggestion here was to create a new abstraction with an API like:

push_notify()

pop_notify()

and then you can implement it with eventfd() pipes/whatever.

What was missing for you of compatfd: qemu_eventfd/qemu_signalfd?
Do a push_notify()/pop_notify() work for you?

Later, Juan.

Re: [PATCH 05/24] compatfd is included before, and it is compiled unconditionally

On Thu, Oct 01, 2009 at 01:58:10PM +0200, Juan Quintela wrote:
> Discused with Anthony about it.  signalfd is complicated for qemu
> upstream (too difficult to use properly), and eventfd ...  The current
> eventfd emulation is worse than the pipe code that it substitutes.
> 
> His suggestion here was to create a new abstraction with an API like:
> 
> push_notify()
> 
> pop_notify()
> 
> and then you can implement it with eventfd() pipes/whatever.
> 
> What was missing for you of compatfd: qemu_eventfd/qemu_signalfd?
> Do a push_notify()/pop_notify() work for you?

I don't desperately want to use it myself anyway.  I just want to get
rid of the highly annoyind spurious differences in the AIO code due
to use of compatfd.  I would be perfectly fine with just killing this
use of eventfd in qemu-kvm.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html