Charles Duffy | 1 Oct 03:51 2009

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

qemu-kvm | 1 Oct 04:05 2009
Picon

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

qemu-kvm | 1 Oct 04:05 2009
Picon

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

Zachary Amsden | 1 Oct 05:05 2009
Picon

[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)
Daniel Gollub | 1 Oct 06:44 2009
Picon

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
(Continue reading)

Mark McLoughlin | 1 Oct 08:59 2009
Picon

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

Avi Kivity | 1 Oct 10:34 2009
Picon

Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server

On 09/30/2009 10:04 PM, Gregory Haskins wrote:

>> A 2.6.27 guest, or Windows guest with the existing virtio drivers, won't work
>> over vbus.
>>      
> Binary compatibility with existing virtio drivers, while nice to have,
> is not a specific requirement nor goal.  We will simply load an updated
> KMP/MSI into those guests and they will work again.  As previously
> discussed, this is how more or less any system works today.  It's like
> we are removing an old adapter card and adding a new one to "uprev the
> silicon".
>    

Virtualization is about not doing that.  Sometimes it's necessary (when 
you have made unfixable design mistakes), but just to replace a bus, 
with no advantages to the guest that has to be changed (other 
hypervisors or hypervisorless deployment scenarios aren't).

>>   Further, non-shmem virtio can't work over vbus.
>>      
> Actually I misspoke earlier when I said virtio works over non-shmem.
> Thinking about it some more, both virtio and vbus fundamentally require
> shared-memory, since sharing their metadata concurrently on both sides
> is their raison d'être.
>
> The difference is that virtio utilizes a pre-translation/mapping (via
> ->add_buf) from the guest side.  OTOH, vbus uses a post translation
> scheme (via memctx) from the host-side.  If anything, vbus is actually
> more flexible because it doesn't assume the entire guest address space
> is directly mappable.
(Continue reading)

Michael S. Tsirkin | 1 Oct 11:28 2009
Picon

Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server

On Thu, Oct 01, 2009 at 10:34:17AM +0200, Avi Kivity wrote:
>> Second, I do not use ioeventfd anymore because it has too many problems
>> with the surrounding technology.  However, that is a topic for a
>> different thread.
>>    
>
> Please post your issues.  I see ioeventfd/irqfd as critical kvm interfaces.

I second that. AFAIK ioeventfd/irqfd got exposed to userspace in 2.6.32-rc1,
if there are issues we better nail them before 2.6.32 is out.
And yes, please start a different thread.

--

-- 
MST

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>

Daniel Schwager | 1 Oct 12:32 2009
Picon

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                                          
(Continue reading)

Daniel Schwager | 1 Oct 13:47 2009
Picon

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


Gmane