date:20100118

[COMMIT master] KVM: ia64: remove redundant kvm_get_exit_data() NULL tests

2010-01-18 Thread Avi Kivity

From: Roel Kluin roel.kl...@gmail.com

kvm_get_exit_data() cannot return a NULL pointer.

Signed-off-by: Roel Kluin roel.kl...@gmail.com
Signed-off-by: Avi Kivity a...@redhat.com

diff --git a/arch/ia64/kvm/kvm_fw.c b/arch/ia64/kvm/kvm_fw.c
index e4b8231..cb548ee 100644
--- a/arch/ia64/kvm/kvm_fw.c
+++ b/arch/ia64/kvm/kvm_fw.c
@@ -75,7 +75,7 @@ static void set_pal_result(struct kvm_vcpu *vcpu,
struct exit_ctl_data *p;
 
p = kvm_get_exit_data(vcpu);
-   if (p  p-exit_reason == EXIT_REASON_PAL_CALL) {
+   if (p-exit_reason == EXIT_REASON_PAL_CALL) {
p-u.pal_data.ret = result;
return ;
}
@@ -87,7 +87,7 @@ static void set_sal_result(struct kvm_vcpu *vcpu,
struct exit_ctl_data *p;
 
p = kvm_get_exit_data(vcpu);
-   if (p  p-exit_reason == EXIT_REASON_SAL_CALL) {
+   if (p-exit_reason == EXIT_REASON_SAL_CALL) {
p-u.sal_data.ret = result;
return ;
}
@@ -322,7 +322,7 @@ static  u64 kvm_get_pal_call_index(struct kvm_vcpu *vcpu)
struct exit_ctl_data *p;
 
p = kvm_get_exit_data(vcpu);
-   if (p  (p-exit_reason == EXIT_REASON_PAL_CALL))
+   if (p-exit_reason == EXIT_REASON_PAL_CALL)
index = p-u.pal_data.gr28;
 
return index;
@@ -646,18 +646,16 @@ static void kvm_get_sal_call_data(struct kvm_vcpu *vcpu, 
u64 *in0, u64 *in1,
 
p = kvm_get_exit_data(vcpu);
 
-   if (p) {
-   if (p-exit_reason == EXIT_REASON_SAL_CALL) {
-   *in0 = p-u.sal_data.in0;
-   *in1 = p-u.sal_data.in1;
-   *in2 = p-u.sal_data.in2;
-   *in3 = p-u.sal_data.in3;
-   *in4 = p-u.sal_data.in4;
-   *in5 = p-u.sal_data.in5;
-   *in6 = p-u.sal_data.in6;
-   *in7 = p-u.sal_data.in7;
-   return ;
-   }
+   if (p-exit_reason == EXIT_REASON_SAL_CALL) {
+   *in0 = p-u.sal_data.in0;
+   *in1 = p-u.sal_data.in1;
+   *in2 = p-u.sal_data.in2;
+   *in3 = p-u.sal_data.in3;
+   *in4 = p-u.sal_data.in4;
+   *in5 = p-u.sal_data.in5;
+   *in6 = p-u.sal_data.in6;
+   *in7 = p-u.sal_data.in7;
+   return ;
}
*in0 = 0;
 }
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[COMMIT master] KVM: fix cleanup_srcu_struct use-after-free

2010-01-18 Thread Avi Kivity

From: Marcelo Tosatti mtosa...@redhat.com

kvm_destroy_vm should free struct kvm after cleanup_srcu_struct.

Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 9843f3d..2b7cd6c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -506,8 +506,8 @@ static void kvm_destroy_vm(struct kvm *kvm)
 #else
kvm_arch_flush_shadow(kvm);
 #endif
-   kvm_arch_destroy_vm(kvm);
cleanup_srcu_struct(kvm-srcu);
+   kvm_arch_destroy_vm(kvm);
hardware_disable_all();
mmdrop(mm);
 }
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[COMMIT master] KVM: PPC: Add helper functions to call real mode loaders

2010-01-18 Thread Avi Kivity

From: Alexander Graf ag...@suse.de

Linux contains quite some bits of code to load FPU, Altivec and VSX lazily for
a task. It calls those bits in real mode, coming from an interrupt handler.

For KVM we better reuse those, so let's wrap a bit of trampoline magic around
them and then we can call them from normal module code.

Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Avi Kivity a...@redhat.com

diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index c7db69f..e1b441c 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -124,6 +124,9 @@ extern void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct 
kvmppc_bat *bat,
 extern u32 kvmppc_trampoline_lowmem;
 extern u32 kvmppc_trampoline_enter;
 extern void kvmppc_rmcall(ulong srr0, ulong srr1);
+extern void kvmppc_load_up_fpu(void);
+extern void kvmppc_load_up_altivec(void);
+extern void kvmppc_load_up_vsx(void);
 
 static inline struct kvmppc_vcpu_book3s *to_book3s(struct kvm_vcpu *vcpu)
 {
diff --git a/arch/powerpc/kvm/book3s_64_exports.c 
b/arch/powerpc/kvm/book3s_64_exports.c
index 99b0712..1dd5a1d 100644
--- a/arch/powerpc/kvm/book3s_64_exports.c
+++ b/arch/powerpc/kvm/book3s_64_exports.c
@@ -23,3 +23,10 @@
 EXPORT_SYMBOL_GPL(kvmppc_trampoline_enter);
 EXPORT_SYMBOL_GPL(kvmppc_trampoline_lowmem);
 EXPORT_SYMBOL_GPL(kvmppc_rmcall);
+EXPORT_SYMBOL_GPL(kvmppc_load_up_fpu);
+#ifdef CONFIG_ALTIVEC
+EXPORT_SYMBOL_GPL(kvmppc_load_up_altivec);
+#endif
+#ifdef CONFIG_VSX
+EXPORT_SYMBOL_GPL(kvmppc_load_up_vsx);
+#endif
diff --git a/arch/powerpc/kvm/book3s_64_rmhandlers.S 
b/arch/powerpc/kvm/book3s_64_rmhandlers.S
index e7091c9..c83c60a 100644
--- a/arch/powerpc/kvm/book3s_64_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_64_rmhandlers.S
@@ -158,6 +158,40 @@ _GLOBAL(kvmppc_rmcall)
mtsrr1  r4
RFI
 
+/*
+ * Activate current's external feature (FPU/Altivec/VSX)
+ */
+#define define_load_up(what)   \
+   \
+_GLOBAL(kvmppc_load_up_ ## what);  \
+   subir1, r1, INT_FRAME_SIZE; \
+   mflrr3; \
+   std r3, _LINK(r1);  \
+   mfmsr   r4; \
+   std r31, GPR3(r1);  \
+   mr  r31, r4;\
+   li  r5, MSR_DR; \
+   orisr5, r5, msr...@h;   \
+   andcr4, r4, r5; \
+   mtmsr   r4; \
+   \
+   bl  .load_up_ ## what;  \
+   \
+   mtmsr   r31;\
+   ld  r3, _LINK(r1);  \
+   ld  r31, GPR3(r1);  \
+   addir1, r1, INT_FRAME_SIZE; \
+   mtlrr3; \
+   blr
+
+define_load_up(fpu)
+#ifdef CONFIG_ALTIVEC
+define_load_up(altivec)
+#endif
+#ifdef CONFIG_VSX
+define_load_up(vsx)
+#endif
+
 .global kvmppc_trampoline_lowmem
 kvmppc_trampoline_lowmem:
.long kvmppc_handler_lowmem_trampoline - _stext
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[COMMIT master] KVM: PPC: Add support for FPU/Altivec/VSX

2010-01-18 Thread Avi Kivity

From: Alexander Graf ag...@suse.de

When our guest starts using either the FPU, Altivec or VSX we need to make
sure Linux knows about it and sneak into its process switching code
accordingly.

This patch makes accesses to the above parts of the system work inside the
VM.

Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Avi Kivity a...@redhat.com

diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index f7215e6..c30a70c 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -172,9 +172,20 @@ struct kvm_vcpu_arch {
struct kvmppc_mmu mmu;
 #endif
 
-   u64 fpr[32];
ulong gpr[32];
 
+   u64 fpr[32];
+   u32 fpscr;
+
+#ifdef CONFIG_ALTIVEC
+   vector128 vr[32];
+   vector128 vscr;
+#endif
+
+#ifdef CONFIG_VSX
+   u64 vsr[32];
+#endif
+
ulong pc;
ulong ctr;
ulong lr;
@@ -188,6 +199,7 @@ struct kvm_vcpu_arch {
 #ifdef CONFIG_PPC64
ulong shadow_msr;
ulong hflags;
+   ulong guest_owned_ext;
 #endif
u32 mmucr;
ulong sprg0;
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 02861fd..2cb1813 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -33,6 +33,9 @@
 
 /* #define EXIT_DEBUG */
 /* #define EXIT_DEBUG_SIMPLE */
+/* #define DEBUG_EXT */
+
+static void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr);
 
 struct kvm_stats_debugfs_item debugfs_entries[] = {
{ exits,   VCPU_STAT(sum_exits) },
@@ -77,6 +80,10 @@ void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu)
memcpy(to_book3s(vcpu)-shadow_vcpu, get_paca()-shadow_vcpu,
   sizeof(get_paca()-shadow_vcpu));
to_book3s(vcpu)-slb_shadow_max = get_paca()-kvm_slb_max;
+
+   kvmppc_giveup_ext(vcpu, MSR_FP);
+   kvmppc_giveup_ext(vcpu, MSR_VEC);
+   kvmppc_giveup_ext(vcpu, MSR_VSX);
 }
 
 #if defined(EXIT_DEBUG)
@@ -97,9 +104,9 @@ void kvmppc_set_msr(struct kvm_vcpu *vcpu, u64 msr)
msr = to_book3s(vcpu)-msr_mask;
vcpu-arch.msr = msr;
vcpu-arch.shadow_msr = msr | MSR_USER32;
-   vcpu-arch.shadow_msr = ( MSR_VEC | MSR_VSX | MSR_FP | MSR_FE0 |
-  MSR_USER64 | MSR_SE | MSR_BE | MSR_DE |
-  MSR_FE1);
+   vcpu-arch.shadow_msr = (MSR_FE0 | MSR_USER64 | MSR_SE | MSR_BE |
+ MSR_DE | MSR_FE1);
+   vcpu-arch.shadow_msr |= (msr  vcpu-arch.guest_owned_ext);
 
if (msr  (MSR_WE|MSR_POW)) {
if (!vcpu-arch.pending_exceptions) {
@@ -551,6 +558,117 @@ int kvmppc_handle_pagefault(struct kvm_run *run, struct 
kvm_vcpu *vcpu,
return r;
 }
 
+static inline int get_fpr_index(int i)
+{
+#ifdef CONFIG_VSX
+   i *= 2;
+#endif
+   return i;
+}
+
+/* Give up external provider (FPU, Altivec, VSX) */
+static void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr)
+{
+   struct thread_struct *t = current-thread;
+   u64 *vcpu_fpr = vcpu-arch.fpr;
+   u64 *vcpu_vsx = vcpu-arch.vsr;
+   u64 *thread_fpr = (u64*)t-fpr;
+   int i;
+
+   if (!(vcpu-arch.guest_owned_ext  msr))
+   return;
+
+#ifdef DEBUG_EXT
+   printk(KERN_INFO Giving up ext 0x%lx\n, msr);
+#endif
+
+   switch (msr) {
+   case MSR_FP:
+   giveup_fpu(current);
+   for (i = 0; i  ARRAY_SIZE(vcpu-arch.fpr); i++)
+   vcpu_fpr[i] = thread_fpr[get_fpr_index(i)];
+
+   vcpu-arch.fpscr = t-fpscr.val;
+   break;
+   case MSR_VEC:
+#ifdef CONFIG_ALTIVEC
+   giveup_altivec(current);
+   memcpy(vcpu-arch.vr, t-vr, sizeof(vcpu-arch.vr));
+   vcpu-arch.vscr = t-vscr;
+#endif
+   break;
+   case MSR_VSX:
+#ifdef CONFIG_VSX
+   __giveup_vsx(current);
+   for (i = 0; i  ARRAY_SIZE(vcpu-arch.vsr); i++)
+   vcpu_vsx[i] = thread_fpr[get_fpr_index(i) + 1];
+#endif
+   break;
+   default:
+   BUG();
+   }
+
+   vcpu-arch.guest_owned_ext = ~msr;
+   current-thread.regs-msr = ~msr;
+   kvmppc_set_msr(vcpu, vcpu-arch.msr);
+}
+
+/* Handle external providers (FPU, Altivec, VSX) */
+static int kvmppc_handle_ext(struct kvm_vcpu *vcpu, unsigned int exit_nr,
+ulong msr)
+{
+   struct thread_struct *t = current-thread;
+   u64 *vcpu_fpr = vcpu-arch.fpr;
+   u64 *vcpu_vsx = vcpu-arch.vsr;
+   u64 *thread_fpr = (u64*)t-fpr;
+   int i;
+
+   if (!(vcpu-arch.msr  msr)) {
+   kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
+   return RESUME_GUEST;
+   }
+
+#ifdef DEBUG_EXT
+   printk(KERN_INFO Loading up ext 0x%lx\n, msr);
+#endif
+
+   current-thread.regs-msr |= msr;
+
+   switch (msr) {
+   case MSR_FP:
+   for (i = 0; i  ARRAY_SIZE(vcpu-arch.fpr); i++)
+

[COMMIT master] KVM: PPC: Fix initial GPR settings

2010-01-18 Thread Avi Kivity

From: Alexander Graf ag...@suse.de

Commit 7d01b4c3ed2bb33ceaf2d270cb4831a67a76b51b introduced PACA backed vcpu
values. With this patch, when a userspace app was setting GPRs before it was
actually first loaded, the set values get discarded.

This is because vcpu_load loads them from the vcpu backing store that we use
whenever we're not owning the PACA.

That behavior is not really a major problem, because we don't need it for
qemu. Other users (like kvmctl) do have problems with it though, so let's
better do it right.

Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Avi Kivity a...@redhat.com

diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index e1b441c..db7db0a 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -22,7 +22,6 @@
 
 #include linux/types.h
 #include linux/kvm_host.h
-#include asm/kvm_ppc.h
 #include asm/kvm_book3s_64_asm.h
 
 struct kvmppc_slb {
diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index 09816da..e264282 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -28,6 +28,9 @@
 #include linux/types.h
 #include linux/kvm_types.h
 #include linux/kvm_host.h
+#ifdef CONFIG_PPC_BOOK3S
+#include asm/kvm_book3s.h
+#endif
 
 enum emulation_result {
EMULATE_DONE, /* no further processing */
@@ -102,9 +105,10 @@ extern void kvmppc_core_destroy_mmu(struct kvm_vcpu *vcpu);
 
 static inline void kvmppc_set_gpr(struct kvm_vcpu *vcpu, int num, ulong val)
 {
-   if ( num  14 )
+   if ( num  14 ) {
get_paca()-shadow_vcpu.gpr[num] = val;
-   else
+   to_book3s(vcpu)-shadow_vcpu.gpr[num] = val;
+   } else
vcpu-arch.gpr[num] = val;
 }
 
@@ -119,6 +123,7 @@ static inline ulong kvmppc_get_gpr(struct kvm_vcpu *vcpu, 
int num)
 static inline void kvmppc_set_cr(struct kvm_vcpu *vcpu, u32 val)
 {
get_paca()-shadow_vcpu.cr = val;
+   to_book3s(vcpu)-shadow_vcpu.cr = val;
 }
 
 static inline u32 kvmppc_get_cr(struct kvm_vcpu *vcpu)
@@ -129,6 +134,7 @@ static inline u32 kvmppc_get_cr(struct kvm_vcpu *vcpu)
 static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, u32 val)
 {
get_paca()-shadow_vcpu.xer = val;
+   to_book3s(vcpu)-shadow_vcpu.xer = val;
 }
 
 static inline u32 kvmppc_get_xer(struct kvm_vcpu *vcpu)
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[COMMIT master] eventfd - allow atomic read and waitqueue remove

2010-01-18 Thread Avi Kivity

From: Davide Libenzi davi...@xmailserver.org

KVM needs a wait to atomically remove themselves from the eventfd -poll()
wait queue head, in order to handle correctly their IRQfd deassign
operation.

This patch introduces such API, plus a way to read an eventfd from its
context.

Signed-off-by: Davide Libenzi davi...@xmailserver.org
Signed-off-by: Avi Kivity a...@redhat.com

diff --git a/fs/eventfd.c b/fs/eventfd.c
index d26402f..7758cc3 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -135,26 +135,71 @@ static unsigned int eventfd_poll(struct file *file, 
poll_table *wait)
return events;
 }
 
-static ssize_t eventfd_read(struct file *file, char __user *buf, size_t count,
-   loff_t *ppos)
+static void eventfd_ctx_do_read(struct eventfd_ctx *ctx, __u64 *cnt)
+{
+   *cnt = (ctx-flags  EFD_SEMAPHORE) ? 1 : ctx-count;
+   ctx-count -= *cnt;
+}
+
+/**
+ * eventfd_ctx_remove_wait_queue - Read the current counter and removes wait 
queue.
+ * @ctx: [in] Pointer to eventfd context.
+ * @wait: [in] Wait queue to be removed.
+ * @cnt: [out] Pointer to the 64bit conter value.
+ *
+ * Returns zero if successful, or the following error codes:
+ *
+ * -EAGAIN  : The operation would have blocked.
+ *
+ * This is used to atomically remove a wait queue entry from the eventfd wait
+ * queue head, and read/reset the counter value.
+ */
+int eventfd_ctx_remove_wait_queue(struct eventfd_ctx *ctx, wait_queue_t *wait,
+ __u64 *cnt)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(ctx-wqh.lock, flags);
+   eventfd_ctx_do_read(ctx, cnt);
+   __remove_wait_queue(ctx-wqh, wait);
+   if (*cnt != 0  waitqueue_active(ctx-wqh))
+   wake_up_locked_poll(ctx-wqh, POLLOUT);
+   spin_unlock_irqrestore(ctx-wqh.lock, flags);
+
+   return *cnt != 0 ? 0 : -EAGAIN;
+}
+EXPORT_SYMBOL_GPL(eventfd_ctx_remove_wait_queue);
+
+/**
+ * eventfd_ctx_read - Reads the eventfd counter or wait if it is zero.
+ * @ctx: [in] Pointer to eventfd context.
+ * @no_wait: [in] Different from zero if the operation should not block.
+ * @cnt: [out] Pointer to the 64bit conter value.
+ *
+ * Returns zero if successful, or the following error codes:
+ *
+ * -EAGAIN  : The operation would have blocked but @no_wait was nonzero.
+ * -ERESTARTSYS : A signal interrupted the wait operation.
+ *
+ * If @no_wait is zero, the function might sleep until the eventfd internal
+ * counter becomes greater than zero.
+ */
+ssize_t eventfd_ctx_read(struct eventfd_ctx *ctx, int no_wait, __u64 *cnt)
 {
-   struct eventfd_ctx *ctx = file-private_data;
ssize_t res;
-   __u64 ucnt = 0;
DECLARE_WAITQUEUE(wait, current);
 
-   if (count  sizeof(ucnt))
-   return -EINVAL;
spin_lock_irq(ctx-wqh.lock);
+   *cnt = 0;
res = -EAGAIN;
if (ctx-count  0)
-   res = sizeof(ucnt);
-   else if (!(file-f_flags  O_NONBLOCK)) {
+   res = 0;
+   else if (!no_wait) {
__add_wait_queue(ctx-wqh, wait);
-   for (res = 0;;) {
+   for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
if (ctx-count  0) {
-   res = sizeof(ucnt);
+   res = 0;
break;
}
if (signal_pending(current)) {
@@ -168,18 +213,32 @@ static ssize_t eventfd_read(struct file *file, char 
__user *buf, size_t count,
__remove_wait_queue(ctx-wqh, wait);
__set_current_state(TASK_RUNNING);
}
-   if (likely(res  0)) {
-   ucnt = (ctx-flags  EFD_SEMAPHORE) ? 1 : ctx-count;
-   ctx-count -= ucnt;
+   if (likely(res == 0)) {
+   eventfd_ctx_do_read(ctx, cnt);
if (waitqueue_active(ctx-wqh))
wake_up_locked_poll(ctx-wqh, POLLOUT);
}
spin_unlock_irq(ctx-wqh.lock);
-   if (res  0  put_user(ucnt, (__u64 __user *) buf))
-   return -EFAULT;
 
return res;
 }
+EXPORT_SYMBOL_GPL(eventfd_ctx_read);
+
+static ssize_t eventfd_read(struct file *file, char __user *buf, size_t count,
+   loff_t *ppos)
+{
+   struct eventfd_ctx *ctx = file-private_data;
+   ssize_t res;
+   __u64 cnt;
+
+   if (count  sizeof(cnt))
+   return -EINVAL;
+   res = eventfd_ctx_read(ctx, file-f_flags  O_NONBLOCK, cnt);
+   if (res  0)
+   return res;
+
+   return put_user(cnt, (__u64 __user *) buf) ? -EFAULT : sizeof(cnt);
+}
 
 static ssize_t eventfd_write(struct file *file, const char __user *buf, size_t 
count,
 loff_t *ppos)
diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h
index 94dd103..91bb4f2 100644
--- a/include/linux/eventfd.h
+++ b/include/linux/eventfd.h
@@ -10,6 +10,7 @@

[COMMIT master] KVM: do not store wqh in irqfd

2010-01-18 Thread Avi Kivity

From: Michael S. Tsirkin m...@redhat.com

wqh is unused, so we do not need to store it in irqfd anymore

Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 486c604..7016319 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -47,7 +47,6 @@ struct _irqfd {
int   gsi;
struct list_head  list;
poll_tablept;
-   wait_queue_head_t*wqh;
wait_queue_t  wait;
struct work_structinject;
struct work_structshutdown;
@@ -159,8 +158,6 @@ irqfd_ptable_queue_proc(struct file *file, 
wait_queue_head_t *wqh,
poll_table *pt)
 {
struct _irqfd *irqfd = container_of(pt, struct _irqfd, pt);
-
-   irqfd-wqh = wqh;
add_wait_queue(wqh, irqfd-wait);
 }
 
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[COMMIT master] KVM: Implement NotifyLongSpinWait HYPER-V hypercall

2010-01-18 Thread Avi Kivity

From: Gleb Natapov g...@redhat.com

Windows issues this hypercall after guest was spinning on a spinlock
for too many iterations.

Signed-off-by: Gleb Natapov g...@redhat.com
Signed-off-by: Vadim Rozenfeld vroze...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 22eb3f0..47c6e23 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1565,6 +1565,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_VCPU_EVENTS:
case KVM_CAP_HYPERV:
case KVM_CAP_HYPERV_VAPIC:
+   case KVM_CAP_HYPERV_SPIN:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
@@ -3828,7 +3829,14 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
 
trace_kvm_hv_hypercall(code, fast, rep_cnt, rep_idx, ingpa, outgpa);
 
-   res = HV_STATUS_INVALID_HYPERCALL_CODE;
+   switch (code) {
+   case HV_X64_HV_NOTIFY_LONG_SPIN_WAIT:
+   kvm_vcpu_on_spin(vcpu);
+   break;
+   default:
+   res = HV_STATUS_INVALID_HYPERCALL_CODE;
+   break;
+   }
 
ret = res | (((u64)rep_done  0xfff)  32);
if (longmode) {
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 5ce6173..4c4937e 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -499,6 +499,7 @@ struct kvm_ioeventfd {
 #define KVM_CAP_PPC_SEGSTATE 43
 #define KVM_CAP_HYPERV 44
 #define KVM_CAP_HYPERV_VAPIC 45
+#define KVM_CAP_HYPERV_SPIN 46
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[COMMIT master] KVM: Implement bare minimum of HYPER-V MSRs

2010-01-18 Thread Avi Kivity

From: Gleb Natapov g...@redhat.com

Minimum HYPER-V implementation should have GUEST_OS_ID, HYPERCALL and
VP_INDEX MSRs.

[avi: fix build on i386]

Signed-off-by: Gleb Natapov g...@redhat.com
Signed-off-by: Vadim Rozenfeld vroze...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com

fix x86 build

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 93bee7a..67d19e4 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -413,6 +413,10 @@ struct kvm_arch {
s64 kvmclock_offset;
 
struct kvm_xen_hvm_config xen_hvm_config;
+
+   /* fields used by HYPER-V emulation */
+   u64 hv_guest_os_id;
+   u64 hv_hypercall;
 };
 
 struct kvm_vm_stat {
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index c584076..ffae142 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -2,6 +2,7 @@
 #define _ASM_X86_KVM_PARA_H
 
 #include linux/types.h
+#include asm/hyperv.h
 
 /* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx.  It
  * should be used to determine that a VM is running under KVM.
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 816e044..1cb3d0e 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -56,6 +56,38 @@ TRACE_EVENT(kvm_hypercall,
 );
 
 /*
+ * Tracepoint for hypercall.
+ */
+TRACE_EVENT(kvm_hv_hypercall,
+   TP_PROTO(__u16 code, bool fast, __u16 rep_cnt, __u16 rep_idx,
+__u64 ingpa, __u64 outgpa),
+   TP_ARGS(code, fast, rep_cnt, rep_idx, ingpa, outgpa),
+
+   TP_STRUCT__entry(
+   __field(__u16,  code)
+   __field(bool,   fast)
+   __field(__u16,  rep_cnt )
+   __field(__u16,  rep_idx )
+   __field(__u64,  ingpa   )
+   __field(__u64,  outgpa  )
+   ),
+
+   TP_fast_assign(
+   __entry-code   = code;
+   __entry-fast   = fast;
+   __entry-rep_cnt= rep_cnt;
+   __entry-rep_idx= rep_idx;
+   __entry-ingpa  = ingpa;
+   __entry-outgpa = outgpa;
+   ),
+
+   TP_printk(code 0x%x %s cnt 0x%x idx 0x%x in 0x%llx out 0x%llx,
+ __entry-code, __entry-fast ? fast : slow,
+ __entry-rep_cnt, __entry-rep_idx,  __entry-ingpa,
+ __entry-outgpa)
+);
+
+/*
  * Tracepoint for PIO.
  */
 TRACE_EVENT(kvm_pio,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4d835b6..68b9ba5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -622,9 +622,10 @@ static inline u32 bit(int bitno)
  * kvm-specific. Those are put in the beginning of the list.
  */
 
-#define KVM_SAVE_MSRS_BEGIN2
+#define KVM_SAVE_MSRS_BEGIN4
 static u32 msrs_to_save[] = {
MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
+   HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
MSR_K6_STAR,
 #ifdef CONFIG_X86_64
@@ -1005,6 +1006,74 @@ out:
return r;
 }
 
+static bool kvm_hv_hypercall_enabled(struct kvm *kvm)
+{
+   return kvm-arch.hv_hypercall  HV_X64_MSR_HYPERCALL_ENABLE;
+}
+
+static bool kvm_hv_msr_partition_wide(u32 msr)
+{
+   bool r = false;
+   switch (msr) {
+   case HV_X64_MSR_GUEST_OS_ID:
+   case HV_X64_MSR_HYPERCALL:
+   r = true;
+   break;
+   }
+
+   return r;
+}
+
+static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data)
+{
+   struct kvm *kvm = vcpu-kvm;
+
+   switch (msr) {
+   case HV_X64_MSR_GUEST_OS_ID:
+   kvm-arch.hv_guest_os_id = data;
+   /* setting guest os id to zero disables hypercall page */
+   if (!kvm-arch.hv_guest_os_id)
+   kvm-arch.hv_hypercall = ~HV_X64_MSR_HYPERCALL_ENABLE;
+   break;
+   case HV_X64_MSR_HYPERCALL: {
+   u64 gfn;
+   unsigned long addr;
+   u8 instructions[4];
+
+   /* if guest os id is not set hypercall should remain disabled */
+   if (!kvm-arch.hv_guest_os_id)
+   break;
+   if (!(data  HV_X64_MSR_HYPERCALL_ENABLE)) {
+   kvm-arch.hv_hypercall = data;
+   break;
+   }
+   gfn = data  HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
+   addr = gfn_to_hva(kvm, gfn);
+   if (kvm_is_error_hva(addr))
+   return 1;
+   kvm_x86_ops-patch_hypercall(vcpu, instructions);
+   ((unsigned char *)instructions)[3] = 0xc3; /* ret */
+   if (copy_to_user((void __user *)addr, instructions, 4))
+   return 1;

Re: [PATCH v3 04/12] Add handle page fault PV helper.

2010-01-18 Thread H. Peter Anvin


On 01/17/2010 06:44 AM, Gleb Natapov wrote:

On Thu, Jan 14, 2010 at 06:31:07PM +0100, Peter Zijlstra wrote:

On Tue, 2010-01-05 at 16:12 +0200, Gleb Natapov wrote:

Allow paravirtualized guest to do special handling for some page faults.

The patch adds one 'if' to do_page_fault() function. The call is patched
out when running on physical HW. I ran kernbech on the kernel with and
without that additional 'if' and result were rawly the same:


So why not program a different handler address for the #PF/#GP faults
and avoid the if all together?

I would gladly use fault vector reserved by x86 architecture, but I am
not sure Intel will be happy about it.



That's what it's there for... see Peter Z.'s response.

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

Re: [PATCH v3 04/12] Add handle page fault PV helper.

2010-01-18 Thread Gleb Natapov

On Mon, Jan 18, 2010 at 12:34:16AM -0800, H. Peter Anvin wrote:
 On 01/17/2010 06:44 AM, Gleb Natapov wrote:
 On Thu, Jan 14, 2010 at 06:31:07PM +0100, Peter Zijlstra wrote:
 On Tue, 2010-01-05 at 16:12 +0200, Gleb Natapov wrote:
 Allow paravirtualized guest to do special handling for some page faults.
 
 The patch adds one 'if' to do_page_fault() function. The call is patched
 out when running on physical HW. I ran kernbech on the kernel with and
 without that additional 'if' and result were rawly the same:
 
 So why not program a different handler address for the #PF/#GP faults
 and avoid the if all together?
 I would gladly use fault vector reserved by x86 architecture, but I am
 not sure Intel will be happy about it.
 
 
 That's what it's there for... see Peter Z.'s response.
 
Do you mean I can use one of exception vectors reserved by Intel
(20-31)? What Peter Z says is that I can register my own handler for
#PF and avoid the 'if' in non PV case as far as I understand him.

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

Re: [PATCH] KVM: Add missing emulation failure report in kvm_mmu_page_fault()

2010-01-18 Thread Sheng Yang

On Sunday 17 January 2010 20:34:23 Avi Kivity wrote:
 On 01/15/2010 10:44 AM, Sheng Yang wrote:
  Currently we only have handle_invalid_guest_state() reported emulation
  failure...
 
  Signed-off-by: Sheng Yangsh...@linux.intel.com
  ---
arch/x86/kvm/mmu.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
 
  diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
  index 4f5508c..037e52a 100644
  --- a/arch/x86/kvm/mmu.c
  +++ b/arch/x86/kvm/mmu.c
  @@ -2791,6 +2791,7 @@ int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t
  cr2, u32 error_code) ++vcpu-stat.mmio_exits;
  return 0;
  case EMULATE_FAIL:
  +   kvm_report_emulation_failure(vcpu, emulation failure);
  vcpu-run-exit_reason = KVM_EXIT_INTERNAL_ERROR;
  vcpu-run-internal.suberror = KVM_INTERNAL_ERROR_EMULATION;
  vcpu-run-internal.ndata = 0;
 
 This is intentional - instead of spamming dmesg, we exit with an
 internal error.  Modern qemu-kvm will halt and allow the user to inspect
 the guest with the built-in disassembler.
 
I think keep it there still useful for some users. And we have the same report 
in handle_invalid_guest_state(), and we even have emulation failure, check 
dmesg for details in QEmu when handling KVM_INTERNAL_ERROR_EMULATION.

I think add one line here is the easiest way to keep consistence, and is 
handy.

-- 
regards
Yang, Sheng
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] KVM: rename is_writeble_pte() to is_writable_pte()

2010-01-18 Thread Takuya Yoshikawa

There are two spellings of writable in
arch/x86/kvm/mmu.c and paging_tmpl.h .

This patch renames is_writeble_pte() to is_writable_pte()
and makes grepping easy.

  New name is consistent with the definition of itself:
  return pte  PT_WRITABLE_MASK;

Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
 arch/x86/kvm/mmu.c |   18 +-
 arch/x86/kvm/paging_tmpl.h |2 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 276bf74..ff2b2e8 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -250,7 +250,7 @@ static int is_large_pte(u64 pte)
return pte  PT_PAGE_SIZE_MASK;
 }
 
-static int is_writeble_pte(unsigned long pte)
+static int is_writable_pte(unsigned long pte)
 {
return pte  PT_WRITABLE_MASK;
 }
@@ -632,7 +632,7 @@ static void rmap_remove(struct kvm *kvm, u64 *spte)
pfn = spte_to_pfn(*spte);
if (*spte  shadow_accessed_mask)
kvm_set_pfn_accessed(pfn);
-   if (is_writeble_pte(*spte))
+   if (is_writable_pte(*spte))
kvm_set_pfn_dirty(pfn);
rmapp = gfn_to_rmap(kvm, sp-gfns[spte - sp-spt], sp-role.level);
if (!*rmapp) {
@@ -708,7 +708,7 @@ static int rmap_write_protect(struct kvm *kvm, u64 gfn)
BUG_ON(!spte);
BUG_ON(!(*spte  PT_PRESENT_MASK));
rmap_printk(rmap_write_protect: spte %p %llx\n, spte, *spte);
-   if (is_writeble_pte(*spte)) {
+   if (is_writable_pte(*spte)) {
__set_spte(spte, *spte  ~PT_WRITABLE_MASK);
write_protected = 1;
}
@@ -732,7 +732,7 @@ static int rmap_write_protect(struct kvm *kvm, u64 gfn)
BUG_ON(!(*spte  PT_PRESENT_MASK));
BUG_ON((*spte  (PT_PAGE_SIZE_MASK|PT_PRESENT_MASK)) != 
(PT_PAGE_SIZE_MASK|PT_PRESENT_MASK));
pgprintk(rmap_write_protect(large): spte %p %llx 
%lld\n, spte, *spte, gfn);
-   if (is_writeble_pte(*spte)) {
+   if (is_writable_pte(*spte)) {
rmap_remove(kvm, spte);
--kvm-stat.lpages;
__set_spte(spte, shadow_trap_nonpresent_pte);
@@ -787,7 +787,7 @@ static int kvm_set_pte_rmapp(struct kvm *kvm, unsigned long 
*rmapp,
 
new_spte = ~PT_WRITABLE_MASK;
new_spte = ~SPTE_HOST_WRITEABLE;
-   if (is_writeble_pte(*spte))
+   if (is_writable_pte(*spte))
kvm_set_pfn_dirty(spte_to_pfn(*spte));
__set_spte(spte, new_spte);
spte = rmap_next(kvm, rmapp, spte);
@@ -1847,7 +1847,7 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
 * is responsibility of mmu_get_page / kvm_sync_page.
 * Same reasoning can be applied to dirty page accounting.
 */
-   if (!can_unsync  is_writeble_pte(*sptep))
+   if (!can_unsync  is_writable_pte(*sptep))
goto set_pte;
 
if (mmu_need_write_protect(vcpu, gfn, can_unsync)) {
@@ -1855,7 +1855,7 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
 __func__, gfn);
ret = 1;
pte_access = ~ACC_WRITE_MASK;
-   if (is_writeble_pte(spte))
+   if (is_writable_pte(spte))
spte = ~PT_WRITABLE_MASK;
}
}
@@ -1876,7 +1876,7 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 
*sptep,
 bool reset_host_protection)
 {
int was_rmapped = 0;
-   int was_writeble = is_writeble_pte(*sptep);
+   int was_writable = is_writable_pte(*sptep);
int rmap_count;
 
pgprintk(%s: spte %llx access %x write_fault %d
@@ -1927,7 +1927,7 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 
*sptep,
if (rmap_count  RMAP_RECYCLE_THRESHOLD)
rmap_recycle(vcpu, sptep, gfn);
} else {
-   if (was_writeble)
+   if (was_writable)
kvm_release_pfn_dirty(pfn);
else
kvm_release_pfn_clean(pfn);
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 58a0f1e..74efcfe 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -160,7 +160,7 @@ walk:
if (rsvd_fault)
goto access_error;
 
-   if (write_fault  !is_writeble_pte(pte))
+   if (write_fault  !is_writable_pte(pte))
if (user_fault || is_write_protection(vcpu))
goto access_error;
 
-- 
1.6.3.3

--
To unsubscribe from this

Re: [PATCH v3 04/12] Add handle page fault PV helper.

2010-01-18 Thread Andi Kleen

Peter Zijlstra pet...@infradead.org writes:

 Whatever are we doing to end up in do_page_fault() as it stands? Surely
 we can tell the CPU to go elsewhere to handle faults?

 Isn't that as simple as calling set_intr_gate(14, my_page_fault)
 somewhere on the cpuinit instead of the regular page_fault handler?

That typically requires ugly ifdefs in entry*S and could be described
as code obfuscation (come from)

As long as he avoids a global reference (patch) the if should be practially
free anyways.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: rename is_writeble_pte() to is_writable_pte()

2010-01-18 Thread Avi Kivity


On 01/18/2010 11:45 AM, Takuya Yoshikawa wrote:

There are two spellings of writable in
arch/x86/kvm/mmu.c and paging_tmpl.h .

This patch renames is_writeble_pte() to is_writable_pte()
and makes grepping easy.

   New name is consistent with the definition of itself:
   return pte  PT_WRITABLE_MASK;

   


Applied, thanks.

--
error compiling committee.c: too many arguments to function

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

Re: [PATCH] KVM: Add missing emulation failure report in kvm_mmu_page_fault()

2010-01-18 Thread Avi Kivity


On 01/18/2010 11:32 AM, Sheng Yang wrote:

On Sunday 17 January 2010 20:34:23 Avi Kivity wrote:
   

On 01/15/2010 10:44 AM, Sheng Yang wrote:
 

Currently we only have handle_invalid_guest_state() reported emulation
failure...
   

This is intentional - instead of spamming dmesg, we exit with an
internal error.  Modern qemu-kvm will halt and allow the user to inspect
the guest with the built-in disassembler.

 

I think keep it there still useful for some users. And we have the same report
in handle_invalid_guest_state(), and we even have emulation failure, check
dmesg for details in QEmu when handling KVM_INTERNAL_ERROR_EMULATION.

I think add one line here is the easiest way to keep consistence, and is
handy.
   


Another way to keep consistency is to remove emulation failure reporting 
in handle_invalid_guest_state() :)


There are two problems with the kernel failure report.  First, it 
doesn't report enough data - registers, surrounding instructions, etc. 
that are needed to explain what is going on.  Second, it can flood 
dmesg, which is a pretty bad thing to do.


I have a patch somewhere that adds instruction emulation bytes (both 
successful and failed) to ftrace.  That may be useful, perhaps.


--
error compiling committee.c: too many arguments to function

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

Re: [PATCH][STABLE-0.12] qemu-kvm: Disable cpu_set command to avoid segfault

2010-01-18 Thread Avi Kivity


On 01/11/2010 07:27 PM, Ryota Ozaki wrote:

CPU hotplug feature is lost in this version. Even worse
cpu_set qemu command may cause segfault.

This patch fix the problem by just disabling it. It is
enough for the stable branch.

Signed-off-by: Ryota Ozakiozaki.ry...@gmail.com
Cc: Gleb Natapovg...@redhat.com
---
  monitor.c |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/monitor.c b/monitor.c
index 6ff6e1f..4b566d2 100644
--- a/monitor.c
+++ b/monitor.c
@@ -829,7 +829,9 @@ static void do_cpu_set_nr(Monitor *mon, const QDict *qdict)
  return;
  }
  #if defined(TARGET_I386) || defined(TARGET_X86_64)
-qemu_system_cpu_hot_add(value, state);
+//qemu_system_cpu_hot_add(value, state);
+monitor_printf(mon, The feature is not avaiable in this version. 
+It will be back in a future version.\n);
  #endif
  }
   


Daniel, how is libvirt going to react to this?

--
error compiling committee.c: too many arguments to function

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

Re: [PATCH][STABLE-0.12] qemu-kvm: Disable cpu_set command to avoid segfault

2010-01-18 Thread Daniel P. Berrange

On Mon, Jan 18, 2010 at 01:34:21PM +0200, Avi Kivity wrote:
 On 01/11/2010 07:27 PM, Ryota Ozaki wrote:
 CPU hotplug feature is lost in this version. Even worse
 cpu_set qemu command may cause segfault.
 
 This patch fix the problem by just disabling it. It is
 enough for the stable branch.
 
 Signed-off-by: Ryota Ozakiozaki.ry...@gmail.com
 Cc: Gleb Natapovg...@redhat.com
 ---
   monitor.c |4 +++-
   1 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/monitor.c b/monitor.c
 index 6ff6e1f..4b566d2 100644
 --- a/monitor.c
 +++ b/monitor.c
 @@ -829,7 +829,9 @@ static void do_cpu_set_nr(Monitor *mon, const QDict 
 *qdict)
   return;
   }
   #if defined(TARGET_I386) || defined(TARGET_X86_64)
 -qemu_system_cpu_hot_add(value, state);
 +//qemu_system_cpu_hot_add(value, state);
 +monitor_printf(mon, The feature is not avaiable in this version. 
 +It will be back in a future version.\n);
   #endif
   }
 
 Daniel, how is libvirt going to react to this?

At this precise point in time it won't react since its not using it, but 
in a week's time when we have finished the libvirt code to use 'cpu_set' 
it'll be less happy !

Can't we actually fix CPU hotplug in the stable tree rather than just
commenting it out ?


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 :|
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][STABLE-0.12] qemu-kvm: Disable cpu_set command to avoid segfault

2010-01-18 Thread Avi Kivity


On 01/18/2010 01:49 PM, Daniel P. Berrange wrote:



Daniel, how is libvirt going to react to this?
 

At this precise point in time it won't react since its not using it, but
in a week's time when we have finished the libvirt code to use 'cpu_set'
it'll be less happy !

Can't we actually fix CPU hotplug in the stable tree rather than just
commenting it out ?
   


We should certainly fix it, but I doubt it's a good fit for the stable tree.

Gleb, what would it take?

--
error compiling committee.c: too many arguments to function

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

Re: [PATCH][STABLE-0.12] qemu-kvm: Disable cpu_set command to avoid segfault

2010-01-18 Thread Gleb Natapov

On Mon, Jan 18, 2010 at 01:57:04PM +0200, Avi Kivity wrote:
 On 01/18/2010 01:49 PM, Daniel P. Berrange wrote:
 
 Daniel, how is libvirt going to react to this?
 At this precise point in time it won't react since its not using it, but
 in a week's time when we have finished the libvirt code to use 'cpu_set'
 it'll be less happy !
 
 Can't we actually fix CPU hotplug in the stable tree rather than just
 commenting it out ?
 
 We should certainly fix it, but I doubt it's a good fit for the stable tree.
 
 Gleb, what would it take?
I have no idea about what causes segfault, so can't really tell how
invasive fix would be, but fixing segfault is not enough we will have to
backport BIOS code to seabios and IMO this code is too much for stable.

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

Re: [PATCH][STABLE-0.12] qemu-kvm: Disable cpu_set command to avoid segfault

2010-01-18 Thread Avi Kivity


On 01/18/2010 02:03 PM, Gleb Natapov wrote:



We should certainly fix it, but I doubt it's a good fit for the stable tree.

Gleb, what would it take?
 

I have no idea about what causes segfault, so can't really tell how
invasive fix would be, but fixing segfault is not enough we will have to
backport BIOS code to seabios and IMO this code is too much for stable.
   


I was asking about the BIOS code.  Can you point me at it?

--
error compiling committee.c: too many arguments to function

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

Re: [PATCH][STABLE-0.12] qemu-kvm: Disable cpu_set command to avoid segfault

2010-01-18 Thread Gleb Natapov

On Mon, Jan 18, 2010 at 02:08:40PM +0200, Avi Kivity wrote:
 On 01/18/2010 02:03 PM, Gleb Natapov wrote:
 
 We should certainly fix it, but I doubt it's a good fit for the stable tree.
 
 Gleb, what would it take?
 I have no idea about what causes segfault, so can't really tell how
 invasive fix would be, but fixing segfault is not enough we will have to
 backport BIOS code to seabios and IMO this code is too much for stable.
 
 I was asking about the BIOS code.  Can you point me at it?
 
This is majority of AML part of it:
http://git.kernel.org/?p=virt/kvm/pcbios.git;a=blob;f=acpi-ssdt.dsl;h=d998867d70b6384c1f40356b9dd8a06b78b59022;hb=master

Seabios should be changed to allocate MADT table from memory that will
be marked as ACPI NVS in e820 and it should pass MADT table address into
AML code somehow (BOCH bios put it at address 0x0514 and AML read it
from there).

Note also that currently seabios created this SSDT dynamically and thus
can support any number of vcpus, by porting those changes we will limit
it to 15 vpus.

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

Re: [PATCH qemu-kvm] device assignment: default requires IOMMU

2010-01-18 Thread Alexander Graf

Chris Wright wrote:
 [ resend, fixing email header, sorry for duplicate ]

 The default mode for device assignment is to rely on an IOMMU for
 proper translations and a functioning device in the guest.  The current
 logic makes this requirement advisory, and simply disables the request
 for IOMMU if one is not found on the host.  This makes for a confused
 user when the device assignment appears to work, but the device in the
 guest is not functioning  (I've seen about a half-dozen reports with
 this failure mode).

 Change the logic such that the default requires the IOMMU.  Period.
 If the host does not have an IOMMU, device assignment will fail.

 This is a user visible change, however I think the current situation is
 simply broken.

 And, of course, disabling the IOMMU requirement using the old:

-pcidevice host=[addr],dma=none

 or the newer:

-device pci-assign,host=[addr],iommu=0

 will do what it always did (not require an IOMMU, and fail to work
 properly).
   

Avi,

could you please cherry-pick this into 0.12-stable?
I don't feel too eager getting 500 bug reports from people who try out
device passthrough with disabled or no IOMMU.

Alex

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

[PATCH] KVM test: Make sure unattended install allways use user nw

2010-01-18 Thread Lucas Meneghel Rodrigues

I have just realized that unattended install wasn't depending
on user mode networking, while it should. Fixing it.

Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
 client/tests/kvm/tests_base.cfg.sample |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/client/tests/kvm/tests_base.cfg.sample 
b/client/tests/kvm/tests_base.cfg.sample
index b1b1539..0ab7823 100644
--- a/client/tests/kvm/tests_base.cfg.sample
+++ b/client/tests/kvm/tests_base.cfg.sample
@@ -60,6 +60,7 @@ variants:
 pre_command = scripts/unattended.py
 floppy = images/floppy.img
 extra_params +=  -boot d
+nic_mode = user
 
 - setup:install unattended_install
 type = steps
-- 
1.6.5.2

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

Re: [PATCH qemu-kvm] device assignment: default requires IOMMU

2010-01-18 Thread Avi Kivity


On 01/18/2010 04:18 PM, Alexander Graf wrote:

Chris Wright wrote:
   

[ resend, fixing email header, sorry for duplicate ]

The default mode for device assignment is to rely on an IOMMU for
proper translations and a functioning device in the guest.  The current
logic makes this requirement advisory, and simply disables the request
for IOMMU if one is not found on the host.  This makes for a confused
user when the device assignment appears to work, but the device in the
guest is not functioning  (I've seen about a half-dozen reports with
this failure mode).

Change the logic such that the default requires the IOMMU.  Period.
If the host does not have an IOMMU, device assignment will fail.

This is a user visible change, however I think the current situation is
simply broken.

And, of course, disabling the IOMMU requirement using the old:

-pcidevice host=[addr],dma=none

or the newer:

-device pci-assign,host=[addr],iommu=0

will do what it always did (not require an IOMMU, and fail to work
properly).

 

Avi,

could you please cherry-pick this into 0.12-stable?
I don't feel too eager getting 500 bug reports from people who try out
device passthrough with disabled or no IOMMU.

   


Makes sense.  Marcelo is committing this week, though.

--
error compiling committee.c: too many arguments to function

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

Re: [Autotest] [PATCH] KVM test: Add PCI device assignment support

2010-01-18 Thread Lucas Meneghel Rodrigues

Ok, after some consideration I have applied the patch:

http://autotest.kernel.org/changeset/4144

Thank you for your work on this test!

On Wed, Jan 13, 2010 at 12:19 AM, Yolkfull Chow yz...@redhat.com wrote:
 On Tue, Jan 12, 2010 at 04:28:13PM -0200, Lucas Meneghel Rodrigues wrote:
 Add support to PCI device assignment on the kvm test. It supports
 both SR-IOV virtual functions and physical NIC card device
 assignment.

 Single Root I/O Virtualization (SR-IOV) allows a single PCI device to
 be shared amongst multiple virtual machines while retaining the
 performance benefit of assigning a PCI device to a virtual machine.
 A common example is where a single SR-IOV capable NIC - with perhaps
 only a single physical network port - might be shared with multiple
 virtual machines by assigning a virtual function to each VM.

 SR-IOV support is implemented in the kernel. The core implementation
 is contained in the PCI subsystem, but there must also be driver support
 for both the Physical Function (PF) and Virtual Function (VF) devices.
 With an SR-IOV capable device one can allocate VFs from a PF. The VFs
 surface as PCI devices which are backed on the physical PCI device by
 resources (queues, and register sets).

 Device support:

 In 2.6.30, the Intel® 82576 Gigabit Ethernet Controller is the only
 SR-IOV capable device supported. The igb driver has PF support and the
 igbvf has VF support.

 In 2.6.31 the Neterion® X3100™ is supported as well. This device uses
 the same vxge driver for the PF as well as the VFs.

 In order to configure the test:

   * For SR-IOV virtual functions passthrough, we could specify the
     module parameter 'max_vfs' in config file.
   * For physical NIC card pass through, we should specify the device
     name(s).

 Looks good for me.
 Lucas, thank you so much for improving this patch. :-)


 Signed-off-by: Yolkfull Chow yz...@redhat.com
 Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
 ---
  client/tests/kvm/kvm_utils.py          |  284 
 
  client/tests/kvm/kvm_vm.py             |   60 +++
  client/tests/kvm/tests_base.cfg.sample |   22 +++-
  3 files changed, 365 insertions(+), 1 deletions(-)

 diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
 index 2bbbe22..a2d9607 100644
 --- a/client/tests/kvm/kvm_utils.py
 +++ b/client/tests/kvm/kvm_utils.py
 @@ -924,3 +924,287 @@ def create_report(report_dir, results_dir):
      reporter = os.path.join(report_dir, 'html_report.py')
      html_file = os.path.join(results_dir, 'results.html')
      os.system('%s -r %s -f %s -R' % (reporter, results_dir, html_file))
 +
 +
 +def get_full_pci_id(pci_id):
 +    
 +    Get full PCI ID of pci_id.
 +
 +   �...@param pci_id: PCI ID of a device.
 +    
 +    cmd = lspci -D | awk '/%s/ {print $1}' % pci_id
 +    status, full_id = commands.getstatusoutput(cmd)
 +    if status != 0:
 +        return None
 +    return full_id
 +
 +
 +def get_vendor_from_pci_id(pci_id):
 +    
 +    Check out the device vendor ID according to pci_id.
 +
 +   �...@param pci_id: PCI ID of a device.
 +    
 +    cmd = lspci -n | awk '/%s/ {print $3}' % pci_id
 +    return re.sub(:,  , commands.getoutput(cmd))
 +
 +
 +class PciAssignable(object):
 +    
 +    Request PCI assignable devices on host. It will check whether to request
 +    PF (physical Functions) or VF (Virtual Functions).
 +    
 +    def __init__(self, type=nic_vf, driver=None, driver_option=None,
 +                 names=None, devices_requested=None):
 +        
 +        Initialize parameter 'type' which could be:
 +        nic_vf: Virtual Functions
 +        nic_pf: Physical Function (actual hardware)
 +        mixed:  Both includes VFs and PFs
 +
 +        If pass through Physical NIC cards, we need to specify which devices
 +        to be assigned, e.g. 'eth1 eth2'.
 +
 +        If pass through Virtual Functions, we need to specify how many vfs
 +        are going to be assigned, e.g. passthrough_count = 8 and max_vfs in
 +        config file.
 +
 +       �...@param type: PCI device type.
 +       �...@param driver: Kernel module for the PCI assignable device.
 +       �...@param driver_option: Module option to specify the maximum 
 number of
 +                VFs (eg 'max_vfs=7')
 +       �...@param names: Physical NIC cards correspondent network 
 interfaces,
 +                e.g.'eth1 eth2 ...'
 +       �...@param devices_requested: Number of devices being requested.
 +        
 +        self.type = type
 +        self.driver = driver
 +        self.driver_option = driver_option
 +        if names:
 +            self.name_list = names.split()
 +        if devices_requested:
 +            self.devices_requested = int(devices_requested)
 +        else:
 +            self.devices_requested = None
 +
 +
 +    def _get_pf_pci_id(self, name, search_str):
 +        
 +        Get the PF PCI ID according to name.
 +
 +       �...@param name: Name of the PCI device.
 +       �...@param

[PATCH] Add definitions for current cpu models..

2010-01-18 Thread john cooper

This is a rework of the prior version which adds definitions
for contemporary processors selected via -cpu model, as an
alternative to the existing use of -cpu qemu64 augmented
with a series of feature flags.

The primary motivation was determination of a least common
denominator within a given processor class to simplify guest
migration.  It is still possible to modify an arbitrary model
via additional feature flags however the goal here was to
make doing so unnecessary in typical usage.  The other
consideration was providing models names reflective of
current processors.  Both AMD and Intel have reviewed the
models in terms of balancing generality of migration vs.
excessive feature downgrade relative to released silicon. 

Concerning the prior version of the patch, the proposed name
used for a given model drew a fair amount of debate, the
main concern being use of names as mnemonic as possible to
the wisest group of users.  Another suggestion was to use
the vendor name of released silicon corresponding to a least
common denominator CPU within the class, rational being doing
so is more definitive of the intended functionality.  However
something like:

 -cpu Intel Core 2 Duo P9xxx

probably isn't all that easy to remember nor type when
selecting a Penryn class cpu.  So I struck what I believe to
be a reasonable compromise where the original x86_def_t.name
was for the most part retained with the x86_def_t.model_id
capturing the marketing name of the cpu being used as the
least common denominator for the class.  To make it easier for
a user to associate a *.name with *.model_id, -cpu ? invoked
rather as -cpu ?? will append *.model_id to the generated
table:

:
x86   Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)   
x86   Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)
x86  Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)   
x86   Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)   
x86   Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)  
x86   Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)
: 

As before a cpu feature 'check' option is added which warns when
feature flags (either implicit in a cpu model or explicit on the
command line) would have otherwise been quietly unavailable to a
guest:

# qemu-system-x86_64 ... -cpu Nehalem,check
warning: host cpuid _0001 lacks requested flag 'sse4.2' [0x0010]
warning: host cpuid _0001 lacks requested flag 'popcnt' [0x0080]

This patch was tested relative to qemu.git.

Signed-off-by: john cooper john.coo...@redhat.com
---

diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index f3834b3..58400ab 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -722,8 +722,8 @@ typedef struct CPUX86State {
 CPUX86State *cpu_x86_init(const char *cpu_model);
 int cpu_x86_exec(CPUX86State *s);
 void cpu_x86_close(CPUX86State *s);
-void x86_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt,
- ...));
+void x86_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
+const char *optarg);
 int cpu_get_pic_interrupt(CPUX86State *s);
 /* MSDOS compatibility mode FPU exception support */
 void cpu_set_ferr(CPUX86State *s);
@@ -875,7 +875,7 @@ uint64_t cpu_get_tsc(CPUX86State *env);
 #define cpu_exec cpu_x86_exec
 #define cpu_gen_code cpu_x86_gen_code
 #define cpu_signal_handler cpu_x86_signal_handler
-#define cpu_list x86_cpu_list
+#define cpu_list_id x86_cpu_list
 
 #define CPU_SAVE_VERSION 11
 
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 730e396..34f4936 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -42,7 +42,7 @@ static const char *feature_name[] = {
 static const char *ext_feature_name[] = {
 pni /* Intel,AMD sse3 */, NULL, NULL, monitor, ds_cpl, vmx, NULL 
/* Linux smx */, est,
 tm2, ssse3, cid, NULL, NULL, cx16, xtpr, NULL,
-NULL, NULL, dca, NULL, NULL, NULL, NULL, popcnt,
+NULL, NULL, dca, sse4.1, sse4.2, x2apic, NULL, popcnt,
 NULL, NULL, NULL, NULL, NULL, NULL, NULL, hypervisor,
 };
 static const char *ext2_feature_name[] = {
@@ -58,6 +58,18 @@ static const char *ext3_feature_name[] = {
 NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 };
 
+/* collects per-function cpuid data
+ */
+typedef struct model_features_t {
+uint32_t *guest_feat;
+uint32_t *host_feat;
+uint32_t check_feat;
+const char **flag_names;
+uint32_t cpuid;
+} model_features_t;
+
+int check_cpuid = 0;
+
 static void add_flagname_to_bitmaps(const char *flagname, uint32_t *features,
 uint32_t *ext_features,
 uint32_t *ext2_features,
@@ -111,10 +123,25 @@ typedef struct x86_def_t {
   CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV | CPUID_PAT | \
   CPUID_PSE36 | CPUID_FXSR)

Re: KVM: MMU: bail out pagewalk on kvm_read_guest error

2010-01-18 Thread Marcelo Tosatti

On Sun, Jan 17, 2010 at 10:23:37AM +0200, Avi Kivity wrote:
 On 01/14/2010 09:41 PM, Marcelo Tosatti wrote:
 Exit the guest pagetable walk loop if reading gpte failed. Otherwise its
 possible to enter an endless loop processing the previous present pte.
 
 Cc: sta...@kernel.org
 Signed-off-by: Marcelo Tosattimtosa...@redhat.com
 
 diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
 index 58a0f1e..ede2131 100644
 --- a/arch/x86/kvm/paging_tmpl.h
 +++ b/arch/x86/kvm/paging_tmpl.h
 @@ -150,7 +150,9 @@ walk:
  walker-table_gfn[walker-level - 1] = table_gfn;
  walker-pte_gpa[walker-level - 1] = pte_gpa;
 
 -kvm_read_guest(vcpu-kvm, pte_gpa,pte, sizeof(pte));
 +if (kvm_read_guest(vcpu-kvm, pte_gpa,pte, sizeof(pte)))
 +goto not_present;
 +
 
 On real hardware, if you place a pte at non-existing memory, you
 aren't guaranteed to get the present bit clear, so why is this
 necessary?
 
 We should be able to survive any garbage the pte previously contained.

The problem is the content of the previous pte is processed (which is
valid), but the cmpxchg fails (see the loop), without level decreasing.

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

Re: KVM: MMU: bail out pagewalk on kvm_read_guest error

2010-01-18 Thread Avi Kivity


On 01/18/2010 07:05 PM, Marcelo Tosatti wrote:

On Sun, Jan 17, 2010 at 10:23:37AM +0200, Avi Kivity wrote:
   

On 01/14/2010 09:41 PM, Marcelo Tosatti wrote:
 

Exit the guest pagetable walk loop if reading gpte failed. Otherwise its
possible to enter an endless loop processing the previous present pte.

Cc: sta...@kernel.org
Signed-off-by: Marcelo Tosattimtosa...@redhat.com

diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 58a0f1e..ede2131 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -150,7 +150,9 @@ walk:
walker-table_gfn[walker-level - 1] = table_gfn;
walker-pte_gpa[walker-level - 1] = pte_gpa;

-   kvm_read_guest(vcpu-kvm, pte_gpa,pte, sizeof(pte));
+   if (kvm_read_guest(vcpu-kvm, pte_gpa,pte, sizeof(pte)))
+   goto not_present;
+
   

On real hardware, if you place a pte at non-existing memory, you
aren't guaranteed to get the present bit clear, so why is this
necessary?

We should be able to survive any garbage the pte previously contained.
 

The problem is the content of the previous pte is processed (which is
valid), but the cmpxchg fails (see the loop), without level decreasing.

   


Yes, you're right.  Patch is fine, then (we could triple-fault instead 
of #PF, but I don't think it matters).


--
error compiling committee.c: too many arguments to function

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

Build problem strikes again

2010-01-18 Thread Lucas Meneghel Rodrigues

Today's git tests failed due to kvm-kmod problems again, please verify:

ERROR   kvm.qemu-kvm-git.build  kvm.qemu-kvm-git.build  
timestamp=1263836706localtime=Jan 18 12:45:06   Command make -j 2 
failed, rc=2, Command returned non-zero exit status
  * Command: 
  make -j 2
  Exit status: 2
  Duration: 0
  
  stdout:
  make -C /lib/modules/2.6.31.6-166.fc12.x86_64/build M=`pwd` \
  LINUXINCLUDE=-I`pwd`/include -Iinclude \
 -Iarch/x86/include \
-I`pwd`/include-compat -I`pwd`/x86 \
-include  include/linux/autoconf.h \
-include `pwd`/x86/external-module-compat.h \
  $@
  make[1]: Entering directory 
`/usr/src/kernels/2.6.31.6-166.fc12.x86_64'
LD  
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/built-in.o
CC [M]  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/svm.o
CC [M]  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.o
  make[1]: Leaving directory 
`/usr/src/kernels/2.6.31.6-166.fc12.x86_64'
  stderr:
  In file included from 
/usr/local/autotest/tests/kvm/src/kvm_kmod/include/linux/kvm_para.h:64,
   from 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/../external-module-compat-comm.h:14,
   from 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/external-module-compat.h:16,
   from command-line:0:
  
/usr/local/autotest/tests/kvm/src/kvm_kmod/include/asm/kvm_para.h:45:24: error: 
asm/hyperv.h: No such file or directory
  In file included from 
/usr/local/autotest/tests/kvm/src/kvm_kmod/include/linux/kvm_para.h:64,
   from 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/../external-module-compat-comm.h:14,
   from 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/external-module-compat.h:16,
   from command-line:0:
  
/usr/local/autotest/tests/kvm/src/kvm_kmod/include/asm/kvm_para.h:45:24: error: 
asm/hyperv.h: No such file or directory
  In file included from 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/irq.h:32,
   from 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.c:58:
  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h: In 
function ‘kvm_hv_vapic_assist_page_enabled’:
  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
error: ‘HV_X64_MSR_APIC_ASSIST_PAGE_ENABLE’ undeclared (first use in this 
function)
  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
error: (Each undeclared identifier is reported only once
  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
error: for each function it appears in.)
  In file included from 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/irq.h:32,
   from 
/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/svm.c:58:
  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h: In 
function ‘kvm_hv_vapic_assist_page_enabled’:
  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
error: ‘HV_X64_MSR_APIC_ASSIST_PAGE_ENABLE’ undeclared (first use in this 
function)
  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
error: (Each undeclared identifier is reported only once
  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
error: for each function it appears in.)
  make[3]: *** 
[/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.o] Error 1
  make[3]: *** Waiting for unfinished jobs
  make[3]: *** 
[/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/svm.o] Error 1
  make[2]: *** [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86] 
Error 2
  make[1]: *** 
[_module_/usr/local/autotest/tests/kvm/src/kvm_kmod] Error 2
  make: *** [all] Error 2

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

understanding KVM versions

2010-01-18 Thread Shi Jin

Hi there,

I am trying to understand the versions of KVM. From what I've learned
so far, there are versions for KVM
   1. qemu-kvm  executable version, obtained for example
   /usr/libexec/qemu-kvm |head -n 1
   2. kvm kernel module version, obtained for example
   modinfo kvm

From http://sourceforge.net/projects/kvm/files/, we see

   * kvm-kmod: listed by linux kernel version such as 2.6.32.3. It
only has kvm-kmod-2.6.32.3.tar.bz2
   * qemu-kvm: listed by release version such as 0.12.1.2. It only
has qemu-kvm-0.12.1.2.tar.gz
   * kvm: listed by snapshot version such as 88. It contains
 o qemu-kvm-devel-88.tar.gz
 o kvm-kmod-devel-88.tar.gz
 o kvm-88.tar.gz: this includes both qemu-kvm and kvm-kmod source
   + / is the same as qemu-kvm
   + kvm/kernel is the same as kvm-kmod

My first question: Is there a one-to-one match between the qemu-kvm
and kvm-kmod versions?
It is straightforward for snapshot development sources, since qemu-kvm
and kvm-kmod come together.
But for stable releases, for a specific kernel version (thus given
kvm-kmod version), should we choose a particular qemu-kvm release
version?

Second question about the virtio drivers: Do a given set of virtio
drivers work only for a specific kvm (kmod and qemu) versions?
The reason I asked this is that I found out the virtio SCSI block
driver works for windows 2008 RC2 on RHEl5.4 hosts but not on Ubuntu
9.10 hosts whose versions are different.
On RHEL 5.4, I have
[r...@node2 NewInstallation]# /usr/libexec/qemu-kvm |head -n 1
QEMU PC emulator version 0.9.1 (kvm-83-maint-snapshot-20090205),
Copyright (c) 2003-2008 Fabrice Bellard

[r...@node2 NewInstallation]# modinfo kvm
filename:   /lib/modules/2.6.18-164.el5/weak-updates/kmod-kvm/kvm.ko
license:GPL
author: Qumranet
version:kvm-83-105.el5
srcversion: 3660497FE5FD1C725B5F09F
depends:
vermagic:   2.6.18-160.el5 SMP mod_unload gcc-4.1
parm:   oos_shadow:bool
parm:   force_kvmclock:bool

On Ubuntu 9.10, I have
onead...@node1:/srv/cloud/ImgRep/VrSTORM/Win08/NewInstallation$ kvm --version
QEMU PC emulator version 0.11.0 (qemu-kvm-0.11.0), Copyright (c)
2003-2008 Fabrice Bellard

onead...@node1:/srv/cloud/ImgRep/VrSTORM/Win08/NewInstallation$ modinfo kvm
filename:   /lib/modules/2.6.31-11-server/kernel/arch/x86/kvm/kvm.ko
license:GPL
author: Qumranet
srcversion: 4BE986C17F9CAF23A6FD6D5
depends:
vermagic:   2.6.31-11-server SMP mod_unload modversions
parm:   oos_shadow:bool

My guess for Window2008 not working on ubuntu is that its
kernel/kvm-kmod version is too new.

I deeply appreciate your answering my two questions. Thanks a lot.

-- 
Shi Jin, Ph.D.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Build problem strikes again

2010-01-18 Thread Gleb Natapov

On Mon, Jan 18, 2010 at 03:24:45PM -0200, Lucas Meneghel Rodrigues wrote:
 Today's git tests failed due to kvm-kmod problems again, please verify:
 
kvm-kmod needs to copy arch/x86/include/asm/hyperv.h during sync now.

   ERROR   kvm.qemu-kvm-git.build  kvm.qemu-kvm-git.build  
 timestamp=1263836706localtime=Jan 18 12:45:06   Command make -j 2 
 failed, rc=2, Command returned non-zero exit status
 * Command: 
 make -j 2
 Exit status: 2
 Duration: 0
 
 stdout:
 make -C /lib/modules/2.6.31.6-166.fc12.x86_64/build M=`pwd` \
 LINUXINCLUDE=-I`pwd`/include -Iinclude \
-Iarch/x86/include \
   -I`pwd`/include-compat -I`pwd`/x86 \
   -include  include/linux/autoconf.h \
   -include `pwd`/x86/external-module-compat.h \
 $@
 make[1]: Entering directory 
 `/usr/src/kernels/2.6.31.6-166.fc12.x86_64'
   LD  
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/built-in.o
   CC [M]  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/svm.o
   CC [M]  /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.o
 make[1]: Leaving directory 
 `/usr/src/kernels/2.6.31.6-166.fc12.x86_64'
 stderr:
 In file included from 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/include/linux/kvm_para.h:64,
  from 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/../external-module-compat-comm.h:14,
  from 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/external-module-compat.h:16,
  from command-line:0:
 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/include/asm/kvm_para.h:45:24: 
 error: asm/hyperv.h: No such file or directory
 In file included from 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/include/linux/kvm_para.h:64,
  from 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/../external-module-compat-comm.h:14,
  from 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/external-module-compat.h:16,
  from command-line:0:
 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/include/asm/kvm_para.h:45:24: 
 error: asm/hyperv.h: No such file or directory
 In file included from 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/irq.h:32,
  from 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.c:58:
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h: In 
 function ‘kvm_hv_vapic_assist_page_enabled’:
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
 error: ‘HV_X64_MSR_APIC_ASSIST_PAGE_ENABLE’ undeclared (first use in this 
 function)
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
 error: (Each undeclared identifier is reported only once
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
 error: for each function it appears in.)
 In file included from 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/irq.h:32,
  from 
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/svm.c:58:
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h: In 
 function ‘kvm_hv_vapic_assist_page_enabled’:
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
 error: ‘HV_X64_MSR_APIC_ASSIST_PAGE_ENABLE’ undeclared (first use in this 
 function)
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
 error: (Each undeclared identifier is reported only once
 /usr/local/autotest/tests/kvm/src/kvm_kmod/x86/lapic.h:57: 
 error: for each function it appears in.)
 make[3]: *** 
 [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/vmx.o] Error 1
 make[3]: *** Waiting for unfinished jobs
 make[3]: *** 
 [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86/svm.o] Error 1
 make[2]: *** [/usr/local/autotest/tests/kvm/src/kvm_kmod/x86] 
 Error 2
 make[1]: *** 
 [_module_/usr/local/autotest/tests/kvm/src/kvm_kmod] Error 2
 make: *** [all] Error 2
 
 --
 To unsubscribe from this list: send the line unsubscribe kvm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: Build problem strikes again

2010-01-18 Thread Jan Kiszka

Gleb Natapov wrote:
 On Mon, Jan 18, 2010 at 03:24:45PM -0200, Lucas Meneghel Rodrigues wrote:
 Today's git tests failed due to kvm-kmod problems again, please verify:

 kvm-kmod needs to copy arch/x86/include/asm/hyperv.h during sync now.
 

Yep, already noticed this in my nightly buildbot run. Will fix soon.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

problem with vm-exit exit code

2010-01-18 Thread Matteo Signorini

Hi guys,

I would like to intercept the vm-exit whenever the guest executes a
lidt/sidt instruction.
I know that lidt/sidt instructions cause a vm-exit if and only if
these condition are satisfied:

   -commands are executed in vmx non-root environment
   -the descriptor-table exiting field of the secondary vm-execution
control structure is enabled

The first condition is satisfied because the guest OS executes the
lidt/sidt in the boot routine so we are in the vmx non-root
environment.
To satisfy the second condition, I set up the 31th bit in the primary
vm-execution control to 1 to enable the secondary vm-execution
control,
then I set up the 2nd bit of the secondary vm-execution control to 1
to enable the descriptor-table exiting.

The problem is that I never get the exit_code=46 (that should
correspond to the IDTR access as shown in the Intel developer's
manual).
What I get is exit_code=0 and then the VM freezes.

I wonder why I get 0 as exit reason instead of 46?

Qemu gives me the following error message:
kvm: unhandled exit 7
kvm_run returned -22

The unhandled exit code correspond to the 7th vm-instruction error
number referred to: VM-Entry with invalid control field(s)

Here are the diffs:

--- x86/default_vmx.c 2010-01-18 11:24:11.726860478 +0100
+++ x86/vmx.c 2010-01-18 11:31:41.116842970 +0100
@@ -2347,6 +2347,7 @@
exec_control = ~SECONDARY_EXEC_ENABLE_EPT;
if (!enable_unrestricted_guest)
exec_control = ~SECONDARY_EXEC_UNRESTRICTED_
GUEST;
+ exec_control |= SECONDARY_EXEC_DT_EXITING;
vmcs_write32(SECONDARY_VM_EXEC_CONTROL, exec_control);
}

@@ -3398,6 +3399,10 @@
vmx-invalid_state_emulation_result = err;
}

+static void handle_gdtr_idtr_access(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run){
+ printk(KERN_INFO line = %d\n,__LINE__);
+}
+
/*
* The exit handlers return 1 if the exit was handled fully and guest execution
* may resume. Otherwise they set the kvm_run parameter to indicate what needs
@@ -3435,6 +3440,7 @@
[EXIT_REASON_MCE_DURING_VMENTRY] =  handle_machine_check,
[EXIT_REASON_EPT_VIOLATION] =handle_ept_violation,
[EXIT_REASON_EPT_MISCONFIG] =   handle_ept_misconfig,
+ [EXIT_REASON_ACCESS_GDTR_IDTR] = handle_gdtr_idtr_access,
};


--- include/asm/default_vmx.h 2010-01-18 11:26:51.126860209 +0100
+++ include/asm/vmx.h 2010-01-18 11:33:23.866760764 +0100
@@ -96,6 +96,7 @@
#define SECONDARY_EXEC_ENABLE_VPID0x0020
#define SECONDARY_EXEC_WBINVD_EXITING0x0040
#define SECONDARY_EXEC_UNRESTRICTED_GUEST 0x0080
+#define SECONDARY_EXEC_DT_EXITING   0x0004


@@ -291,6 +292,7 @@
#define EXIT_REASON_MCE_DURING_VMENTRY   41
#define EXIT_REASON_TPR_BELOW_THRESHOLD43
#define EXIT_REASON_APIC_ACCESS   44
+#define EXIT_REASON_ACCESS_GDTR_IDTR   46
#define EXIT_REASON_EPT_VIOLATION 48
#define EXIT_REASON_EPT_MISCONFIG49
#define EXIT_REASON_WBINVD54

-

I am on an Intel Intel Core2 Duo P8700 CPU, Ubuntu 9.10 with kernel
2.6.31-17-generic, kvm 2.6.32.3 and qemu 0.12.1.1
What am I doing wrong???
Thanks

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

KVM call agenda for Jan 19

2010-01-18 Thread Chris Wright

Please send in any agenda items you are interested in covering in
tomorrow's call.

thanks,
-chris
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 04/12] Add handle page fault PV helper.

2010-01-18 Thread H. Peter Anvin

On 01/18/2010 12:50 AM, Gleb Natapov wrote:
 On Mon, Jan 18, 2010 at 12:34:16AM -0800, H. Peter Anvin wrote:
 On 01/17/2010 06:44 AM, Gleb Natapov wrote:
 On Thu, Jan 14, 2010 at 06:31:07PM +0100, Peter Zijlstra wrote:
 On Tue, 2010-01-05 at 16:12 +0200, Gleb Natapov wrote:
 Allow paravirtualized guest to do special handling for some page faults.

 The patch adds one 'if' to do_page_fault() function. The call is patched
 out when running on physical HW. I ran kernbech on the kernel with and
 without that additional 'if' and result were rawly the same:

 So why not program a different handler address for the #PF/#GP faults
 and avoid the if all together?
 I would gladly use fault vector reserved by x86 architecture, but I am
 not sure Intel will be happy about it.


 That's what it's there for... see Peter Z.'s response.

 Do you mean I can use one of exception vectors reserved by Intel
 (20-31)? What Peter Z says is that I can register my own handler for
 #PF and avoid the 'if' in non PV case as far as I understand him.
 

What I mean is that vector 14 is page faults -- that's what it is all
about.  Why on Earth do you need another vector?

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

Re: [PATCH] KVM: Add missing emulation failure report in kvm_mmu_page_fault()

2010-01-18 Thread Sheng Yang

On Monday 18 January 2010 19:32:14 Avi Kivity wrote:
 On 01/18/2010 11:32 AM, Sheng Yang wrote:
  On Sunday 17 January 2010 20:34:23 Avi Kivity wrote:
  On 01/15/2010 10:44 AM, Sheng Yang wrote:
  Currently we only have handle_invalid_guest_state() reported emulation
  failure...
 
  This is intentional - instead of spamming dmesg, we exit with an
  internal error.  Modern qemu-kvm will halt and allow the user to inspect
  the guest with the built-in disassembler.
 
  I think keep it there still useful for some users. And we have the same
  report in handle_invalid_guest_state(), and we even have emulation
  failure, check dmesg for details in QEmu when handling
  KVM_INTERNAL_ERROR_EMULATION.
 
  I think add one line here is the easiest way to keep consistence, and is
  handy.
 
 Another way to keep consistency is to remove emulation failure reporting
 in handle_invalid_guest_state() :)

OK, I would remove it...
 
 There are two problems with the kernel failure report.  First, it
 doesn't report enough data - registers, surrounding instructions, etc.
 that are needed to explain what is going on.  Second, it can flood
 dmesg, which is a pretty bad thing to do.
 
When you talking about built-in disassembler, do you talking about 
memsave/objdump or some other more convenient way for this?

And maybe we can let QEmu do some dump of the assembler code? 
(kvm_show_code())

 I have a patch somewhere that adds instruction emulation bytes (both
 successful and failed) to ftrace.  That may be useful, perhaps.

It would surely help. :)

-- 
regards
Yang, Sheng

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

Re: [PATCH v3 04/12] Add handle page fault PV helper.

2010-01-18 Thread Gleb Natapov

On Mon, Jan 18, 2010 at 05:53:53PM -0800, H. Peter Anvin wrote:
 On 01/18/2010 12:50 AM, Gleb Natapov wrote:
  On Mon, Jan 18, 2010 at 12:34:16AM -0800, H. Peter Anvin wrote:
  On 01/17/2010 06:44 AM, Gleb Natapov wrote:
  On Thu, Jan 14, 2010 at 06:31:07PM +0100, Peter Zijlstra wrote:
  On Tue, 2010-01-05 at 16:12 +0200, Gleb Natapov wrote:
  Allow paravirtualized guest to do special handling for some page faults.
 
  The patch adds one 'if' to do_page_fault() function. The call is patched
  out when running on physical HW. I ran kernbech on the kernel with and
  without that additional 'if' and result were rawly the same:
 
  So why not program a different handler address for the #PF/#GP faults
  and avoid the if all together?
  I would gladly use fault vector reserved by x86 architecture, but I am
  not sure Intel will be happy about it.
 
 
  That's what it's there for... see Peter Z.'s response.
 
  Do you mean I can use one of exception vectors reserved by Intel
  (20-31)? What Peter Z says is that I can register my own handler for
  #PF and avoid the 'if' in non PV case as far as I understand him.
  
 
 What I mean is that vector 14 is page faults -- that's what it is all
 about.  Why on Earth do you need another vector?
 
Because this is not usual pagefault that tell the OS that page is not
mapped. This is a notification to a guest OS that the page it is trying
to access is swapped out by the host OS. There is nothing guest can do
about it except schedule another task. So the guest should handle both
type of exceptions: usual #PF when page is not mapped by the guest and
new type of notifications. Ideally we would use one of unused exception
vectors for new type of notifications.

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

Re: [PATCH] KVM: Add missing emulation failure report in kvm_mmu_page_fault()

2010-01-18 Thread Avi Kivity


On 01/19/2010 05:06 AM, Sheng Yang wrote:



There are two problems with the kernel failure report.  First, it
doesn't report enough data - registers, surrounding instructions, etc.
that are needed to explain what is going on.  Second, it can flood
dmesg, which is a pretty bad thing to do.
 


When you talking about built-in disassembler, do you talking about
memsave/objdump or some other more convenient way for this?

And maybe we can let QEmu do some dump of the assembler code?
(kvm_show_code())
   


In the qemu monitor, type 'x/20i $eip' to get a disassembly of code 
around the current instruction pointer.



I have a patch somewhere that adds instruction emulation bytes (both
successful and failed) to ftrace.  That may be useful, perhaps.
 

It would surely help. :)
   


I'll try to resurrect it.

--
error compiling committee.c: too many arguments to function

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

Re: [PATCH] KVM: Add missing emulation failure report in kvm_mmu_page_fault()

2010-01-18 Thread Gleb Natapov

On Tue, Jan 19, 2010 at 09:54:44AM +0200, Avi Kivity wrote:
 On 01/19/2010 05:06 AM, Sheng Yang wrote:
 
 There are two problems with the kernel failure report.  First, it
 doesn't report enough data - registers, surrounding instructions, etc.
 that are needed to explain what is going on.  Second, it can flood
 dmesg, which is a pretty bad thing to do.
 
 When you talking about built-in disassembler, do you talking about
 memsave/objdump or some other more convenient way for this?
 
 And maybe we can let QEmu do some dump of the assembler code?
 (kvm_show_code())
 
 In the qemu monitor, type 'x/20i $eip' to get a disassembly of code
 around the current instruction pointer.
 
If you want to see code _around_ the current instruction pointer type
'x/20i $eip-20' :) Or that is what I usually do.

 I have a patch somewhere that adds instruction emulation bytes (both
 successful and failed) to ftrace.  That may be useful, perhaps.
 It would surely help. :)
 
 I'll try to resurrect it.
 
 -- 
 error compiling committee.c: too many arguments to function
 
 --
 To unsubscribe from this list: send the line unsubscribe kvm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Autotest PATCH] KVM-test: Fix a bug that pci_assignable type name mismatch

2010-01-18 Thread Yolkfull Chow

The pci_assignable type name is nic_vf/nic_pf in kvm_utils.py whereas
in kvm_vm.py they are vf/pf. Weird that why I tested it pass last week.
Hope that it will not bring in any trouble before this patch applied.

Signed-off-by: Yolkfull Chow yz...@redhat.com
---
 client/tests/kvm/kvm_utils.py |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
index 83aff66..df26a77 100644
--- a/client/tests/kvm/kvm_utils.py
+++ b/client/tests/kvm/kvm_utils.py
@@ -971,12 +971,12 @@ class PciAssignable(object):
 Request PCI assignable devices on host. It will check whether to request
 PF (physical Functions) or VF (Virtual Functions).
 
-def __init__(self, type=nic_vf, driver=None, driver_option=None,
+def __init__(self, type=vf, driver=None, driver_option=None,
  names=None, devices_requested=None):
 
 Initialize parameter 'type' which could be:
-nic_vf: Virtual Functions
-nic_pf: Physical Function (actual hardware)
+vf: Virtual Functions
+pf: Physical Function (actual hardware)
 mixed:  Both includes VFs and PFs
 
 If pass through Physical NIC cards, we need to specify which devices
@@ -1087,9 +1087,9 @@ class PciAssignable(object):
 @param count: count number of PCI devices needed for pass through
 @return: a list of all devices' PCI IDs
 
-if self.type == nic_vf:
+if self.type == vf:
 vf_ids = self.get_vf_devs()
-elif self.type == nic_pf:
+elif self.type == pf:
 vf_ids = self.get_pf_devs()
 elif self.type == mixed:
 vf_ids = self.get_vf_devs()
-- 
1.5.5.6

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

41 matches

Mail list logo