Re: [KVM-AUTOTEST PATCH] kvm_utils.py: remote_login(): improve regular expression matching

2009-05-29 Thread Lucas Meneghel Rodrigues
On Sun, 2009-05-24 at 18:46 +0300, Michael Goldish wrote: 1. Make the 'login:' regular expression stricter so it doesn't match 'Last login: ...' messages. 2. Make the 'password:' regular expression stricter. 3. Handle 'Connection refused' messages. Looks good to me Signed-off-by: Michael

[PATCH] KVM: add localversion to avoid confusion and conflicts

2009-05-29 Thread Jaswinder Singh Rajput
Adding localversion avoids confusion in kernel images : like Linux version 2.6.30-rc7 does not tell whether it is linus or kvm kernel. By adding localversion it tells : Linux version 2.6.30-rc7-kvm , any doubt ;-) Secondly, by installing modules it overwrites on linus modules. By adding

Re: [PATCH] KVM: add localversion to avoid confusion and conflicts

2009-05-29 Thread Christian Bornträger
Am Freitag 29 Mai 2009 09:18:14 schrieb Jaswinder Singh Rajput: Adding localversion avoids confusion in kernel images : like Linux version 2.6.30-rc7 does not tell whether it is linus or kvm kernel. By adding localversion it tells : Linux version 2.6.30-rc7-kvm , any doubt ;-) I am

[PATCH 2/5] kvm-s390: fix interruption casued by signal - v2

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com *updates in v2* merged a small piece of code from patch 1/1 that belongs here themtically If signal pending is true we exit without updating kvm_run, userspace currently just does nothing and jumps to kvm_run again. Since we did not set an

[PATCH 1/5] kvm-s390: infrastructure to kick vcpus out of guest state - v3

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com *updates in v3* - ensure allocations (might_sleep) are out of atomic context *updates in v2* instead of a kick to level behaviour the patch now implements a kick to the lowest level. The check there bails out to upper levels if not all

[PATCH 3/5] kvm-s390: update vcpu-cpu

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com kvm on s390 formerly ignored vcpu-cpu. This patch adds set/unset vcpu-cpu in kvm_arch_vcpu_load/put to allow further architecture unification e.g. let generic code not find -1 on currently scheduled vcpus. Signed-off-by: Christian Ehrhardt

[PATCH 4/5] kvm: remove redundant declarations

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com Changing s390 code in kvm_arch_vcpu_load/put come across this header declarations. They are complete duplicates, not even useful forward declarations as nothing using it is in between (maybe it was that in the past). This patch removes the two

[PATCH 5/5] kvm-s390: streamline memslot handling - v5

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com *updates in v5* - ensure dropping all vcpu requests while freeing a vcpu *updates in v4* - kickout only scheduled vcpus (its superfluous and wait might hang forever on not running vcpus) *updates in v3* - handling the mmu reload vcpu

[PATCH 0/5] kvm-s390: revised version of kvm-s390 guest memory handling - v5

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@de.ibm.com *updates in v5* - ensure dropping all vcpu requests while freeing a vcpu *updates in v4* - ensure kick allocations (might_sleep) are out of atomic context - update vcpu-cpu in kvm-s390 arch handler for load/put - remove a redundant declaration in

Lost interrupts with upstream KVM

2009-05-29 Thread Jan Kiszka
Hi Gleb, with latest kernel modules, namely beginning with 6bc0a1a235 (Remove irq_pending bitmap), I'm loosing interrupts with upstream's KVM support. After some bisecting, hair-pulling and a bit meditation I added a WARN_ON(kvm_cpu_has_interrupt(vcpu)) to kvm_vcpu_ioctl_interrupt, and it

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Gleb Natapov
On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote: Hi Gleb, with latest kernel modules, namely beginning with 6bc0a1a235 (Remove irq_pending bitmap), I'm loosing interrupts with upstream's KVM support. After some bisecting, hair-pulling and a bit meditation I added a

Re: Remove qemu_alloc_physram()

2009-05-29 Thread Avi Kivity
Ryan Harper wrote: This patch restores -mempath working for me on latest qemu-kvm.git. Thanks for confirming. btw, why'd we go from -mem-path (kvm-84/stable) to -mempath (kvm-85 and newer)? Changing these breaks existing scripts. Not a big deal, but wondering what was the motivation for

Re: [PATCH] KVM: add localversion to avoid confusion and conflicts

2009-05-29 Thread Jaswinder Singh Rajput
On Fri, 2009-05-29 at 09:48 +0200, Christian Bornträger wrote: Am Freitag 29 Mai 2009 09:18:14 schrieb Jaswinder Singh Rajput: Adding localversion avoids confusion in kernel images : like Linux version 2.6.30-rc7 does not tell whether it is linus or kvm kernel. By adding localversion

Re: [PATCH] KVM: add localversion to avoid confusion and conflicts

2009-05-29 Thread Christian Bornträger
Am Freitag 29 Mai 2009 10:43:46 schrieb Jaswinder Singh Rajput: Adding localversion avoids confusion in kernel images : NAK from my side. If you need a distinction, there is always Here is NAK for your NAK from my side. This patch is only for KVM tree and not for linus tree. I know that

Re: Userspace MSR handling

2009-05-29 Thread Gerd Hoffmann
On 05/28/09 10:53, Avi Kivity wrote: Gerd Hoffmann wrote: Trying to use in-kernel xen netback driver adds this problem: * Host kernel does xen hypercalls. Ouch. We have to emulate them in-kernel (otherwise using in-kernel netback would be a quite pointless exercise). Or do the standard

unhandled vm exit: 0x80000021 vcpu_id 0

2009-05-29 Thread Gabe Black
Hello again. I'm making more progress getting KVM going in M5, and right now I'm trying to figure out why I'm getting an unhandled vm exit with exit code 0x8021. According to Intel's manual, something about the guest state isn't being set up correctly. I dumped the initial register

[PATCH 3/4] kvm-s390: update vcpu-cpu

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com kvm on s390 formerly ignored vcpu-cpu. This patch adds set/unset vcpu-cpu in kvm_arch_vcpu_load/put to allow further architecture unification e.g. let generic code not find -1 on currently scheduled vcpus. Signed-off-by: Christian Ehrhardt

[PATCH 4/4] kvm-s390: streamline memslot handling - v6

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com *updates in v6* - ensure the wait_on_bit waiter is notified - move the reset of requests to kvm_vcpu_release to drop them early *updates in v5* - ensure dropping vcpu all requests while freeing a vcpu *updates in v4* - kickout only scheduled

[PATCH 2/4] kvm-s390: fix interruption caused by signal - v2

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com *updates in v2* merged a small piece of code from patch 1/1 that belongs here themtically If signal pending is true we exit without updating kvm_run, userspace currently just does nothing and jumps to kvm_run again. Since we did not set an

[PATCH] kvm: remove redundant declarations

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com Changing s390 code in kvm_arch_vcpu_load/put come across this header declarations. They are complete duplicates, not even useful forward declarations as nothing using it is in between (maybe it was that in the past). This patch removes the two

[PATCH 1/4] kvm-s390: infrastructure to kick vcpus out of guest state - v3

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@linux.vnet.ibm.com *updates in v3* - ensure allocations (might_sleep) are out of atomic context *updates in v2* instead of a kick to level behaviour the patch now implements a kick to the lowest level. The check there bails out to upper levels if not all

[PATCH 0/4] kvm-s390: revised version of kvm-s390 guest memory handling - v6

2009-05-29 Thread ehrhardt
From: Christian Ehrhardt ehrha...@de.ibm.com *updates in v6* - drop the unrelated fix to kvm_host.h from the series to clear it thematically - ensure the wait_on_bit waiter is notified - move the reset of requests to kvm_vcpu_release to drop them early Note: I beg a pardon for the change rate of

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Gleb Natapov
On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote: Hi Gleb, with latest kernel modules, namely beginning with 6bc0a1a235 (Remove irq_pending bitmap), I'm loosing interrupts with upstream's KVM support. After some bisecting, hair-pulling and a bit meditation I added a

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Jan Kiszka
Gleb Natapov wrote: On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote: Hi Gleb, with latest kernel modules, namely beginning with 6bc0a1a235 (Remove irq_pending bitmap), I'm loosing interrupts with upstream's KVM support. After some bisecting, hair-pulling and a bit meditation I

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Gleb Natapov
On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote: Hi Gleb, with latest kernel modules, namely beginning with 6bc0a1a235 (Remove irq_pending bitmap), I'm loosing interrupts with upstream's KVM

BUG at mmu.c:615 from localhost migration using ept+hugetlbfs

2009-05-29 Thread Ryan Harper
Testing latest qemu-kvm.git and kvm-kmod.git, ept enabled and backing guests with large pages trips a BUG in the mmu code. If I disable ept, but still use large pages, migration succeeds. Reproduce with: hugetlbfs setup: % mkdir -p /hugetlbfs mount -t hugetlbfs hugetlbfs /hugetlbfs % echo

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Jan Kiszka
Gleb Natapov wrote: On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote: Hi Gleb, with latest kernel modules, namely beginning with 6bc0a1a235 (Remove irq_pending bitmap), I'm loosing interrupts with

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Gleb Natapov
On Fri, May 29, 2009 at 06:46:47PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote: Hi Gleb, with latest kernel modules, namely beginning with

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Jan Kiszka
Gleb Natapov wrote: On Fri, May 29, 2009 at 06:46:47PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote: Hi Gleb, with latest kernel modules, namely

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Gleb Natapov
On Fri, May 29, 2009 at 07:01:44PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 06:46:47PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 10:23:24AM +0200, Jan

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Jan Kiszka
Gleb Natapov wrote: On Fri, May 29, 2009 at 07:01:44PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 06:46:47PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Fri, May 29, 2009 at

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Gleb Natapov
On Fri, May 29, 2009 at 07:26:52PM +0200, Jan Kiszka wrote: with latest kernel modules, namely beginning with 6bc0a1a235 (Remove irq_pending bitmap), I'm loosing interrupts with upstream's KVM support. After some bisecting, hair-pulling and a bit meditation I added a

Re: Lost interrupts with upstream KVM

2009-05-29 Thread Jan Kiszka
Gleb Natapov wrote: On Fri, May 29, 2009 at 07:26:52PM +0200, Jan Kiszka wrote: with latest kernel modules, namely beginning with 6bc0a1a235 (Remove irq_pending bitmap), I'm loosing interrupts with upstream's KVM support. After some bisecting, hair-pulling and a bit meditation I added a

RE: Status of pci passthrough work?

2009-05-29 Thread Passera, Pablo R
Hi Amit, Please correct me if I am wrong, but the fact that the PVDMA module is located in the guest imposes a security problem. So, if someone in the guest has root access, he could modify the PVDMA module and then corrupt the host memory. Because of this the guest has to be trusted.

Re: [PATCH -tip v8 6/7] tracing: ftrace dynamic ftrace_event_call support

2009-05-29 Thread Steven Rostedt
On Thu, 28 May 2009, Masami Hiramatsu wrote: Add dynamic ftrace_event_call support to ftrace. Trace engines can adds new ftrace_event_call to ftrace on the fly. Each operator functions of the call takes a ftrace_event_call data structure as an argument, because these functions may be shared

Re: [PATCH -tip v8 7/7] tracing: add kprobe-based event tracer

2009-05-29 Thread Steven Rostedt
On Thu, 28 May 2009, Masami Hiramatsu wrote: Add kprobes-based event tracer on ftrace. This tracer is similar to the events tracer which is based on Tracepoint infrastructure. Instead of Tracepoint, this tracer is based on kprobes(kprobe and kretprobe). It probes anywhere where kprobes can

Re: [PATCH -tip v8 7/7] tracing: add kprobe-based event tracer

2009-05-29 Thread Steven Rostedt
On Thu, 28 May 2009, Masami Hiramatsu wrote: +#undef SHOW_FIELD +#define SHOW_FIELD(type, item, name) \ + do {\ + ret = trace_seq_printf(s, \tfield: #type %s;\t\ +