Re: [PATCH v4 2/2] KVM: s390: use cookies for ioeventfd

2013-07-14 Thread Gleb Natapov
On Thu, Jul 04, 2013 at 08:54:32AM +0200, Paolo Bonzini wrote:
 Il 03/07/2013 18:33, Cornelia Huck ha scritto:
  On Wed, 03 Jul 2013 17:30:40 +0200
  Paolo Bonzini pbonz...@redhat.com wrote:
  
  Il 03/07/2013 16:30, Cornelia Huck ha scritto:
  + /*
  +  * Return cookie in gpr 2, but don't overwrite the register if the
  +  * diagnose will be handled by userspace.
  +  */
  + if (ret != -EOPNOTSUPP)
  + vcpu-run-s.regs.gprs[2] = ret;
 
  I think this should now be if (ret = 0).
  
  Hm, we don't want to kill gpr 2's old contents if userspace will do
  something, which means -EOPNOTSUPP.
 
 In the end kvm_io_bus_write_cookie only returns -EOPNOTSUPP if there is
 an error, so it works.  But if this were to change, the code would
 break.  That's why I suggested testing ret = 0 rather than ret !=
 -EOPNOTSUPP.  But in the end it is the same.
 
 
/* kvm_io_bus_write returns -EOPNOTSUPP if it found no match. */
 
  The comment is now obsolete.
  
  s/kvm_io_bus_write/kvm_io_bus_write_cookie/ ? Otherwise, this is still
  true.
 
 True but somewhat misplaced, it is basically saying the same thing as
 the Return cookie in gpr 2 comment just above.
 
 Anyhow, these are very small details.  I changed kvm_io_bus_write to
 kvm_io_bus_write_cookie in the comment and applied the patches to kvm-queue.
 
1/2 broke x86. QEMU prints Invalid read from memory region kvm-pic and
guest hangs. Looks like IO is forwarded to userspace instead of in kernel device
for some reason. Un-applying for now.

--
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 v4 2/2] KVM: s390: use cookies for ioeventfd

2013-07-14 Thread Gleb Natapov
On Sun, Jul 14, 2013 at 12:25:16PM +0300, Gleb Natapov wrote:
 On Thu, Jul 04, 2013 at 08:54:32AM +0200, Paolo Bonzini wrote:
  Il 03/07/2013 18:33, Cornelia Huck ha scritto:
   On Wed, 03 Jul 2013 17:30:40 +0200
   Paolo Bonzini pbonz...@redhat.com wrote:
   
   Il 03/07/2013 16:30, Cornelia Huck ha scritto:
   +   /*
   +* Return cookie in gpr 2, but don't overwrite the register if 
   the
   +* diagnose will be handled by userspace.
   +*/
   +   if (ret != -EOPNOTSUPP)
   +   vcpu-run-s.regs.gprs[2] = ret;
  
   I think this should now be if (ret = 0).
   
   Hm, we don't want to kill gpr 2's old contents if userspace will do
   something, which means -EOPNOTSUPP.
  
  In the end kvm_io_bus_write_cookie only returns -EOPNOTSUPP if there is
  an error, so it works.  But if this were to change, the code would
  break.  That's why I suggested testing ret = 0 rather than ret !=
  -EOPNOTSUPP.  But in the end it is the same.
  
  
   /* kvm_io_bus_write returns -EOPNOTSUPP if it found no match. */
  
   The comment is now obsolete.
   
   s/kvm_io_bus_write/kvm_io_bus_write_cookie/ ? Otherwise, this is still
   true.
  
  True but somewhat misplaced, it is basically saying the same thing as
  the Return cookie in gpr 2 comment just above.
  
  Anyhow, these are very small details.  I changed kvm_io_bus_write to
  kvm_io_bus_write_cookie in the comment and applied the patches to kvm-queue.
  
 1/2 broke x86. QEMU prints Invalid read from memory region kvm-pic and
 guest hangs. Looks like IO is forwarded to userspace instead of in kernel 
 device
 for some reason. Un-applying for now.
 
OK, stupid typo. Will amend the commit instead of dropping.


diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 6cde6fa..a86735d 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2942,7 +2942,7 @@ static int __kvm_io_bus_read(struct kvm_io_bus *bus, 
struct kvm_io_range *range,
return -EOPNOTSUPP;
 
while (idx  bus-dev_count 
-   kvm_io_bus_sort_cmp(range, bus-range[idx]) == 0) {
+   kvm_io_bus_sort_cmp(range, bus-range[idx]) == 0) {
if (!kvm_iodevice_read(bus-range[idx].dev, range-addr,
   range-len, val))
return idx;
--
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


[Bug 60271] Kernelpanic since 3.9.8 with qemu-kvm and pci-passthrough

2013-07-14 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=60271

--- Comment #11 from Michael S. Tsirkin m.s.tsir...@gmail.com ---
could you test latest upstream please?
A fix from there is in the process of being backported to stable.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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 RFC V10 15/18] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

2013-07-14 Thread Gleb Natapov
On Mon, Jun 24, 2013 at 06:13:42PM +0530, Raghavendra K T wrote:
 kvm : Paravirtual ticketlocks support for linux guests running on KVM 
 hypervisor
 
 From: Srivatsa Vaddagiri va...@linux.vnet.ibm.com
 
 During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
 required feature (KVM_FEATURE_PV_UNHALT) to support pv-ticketlocks. If so,
  support for pv-ticketlocks is registered via pv_lock_ops.
 
 Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
 
 Signed-off-by: Srivatsa Vaddagiri va...@linux.vnet.ibm.com
 Signed-off-by: Suzuki Poulose suz...@in.ibm.com
 [Raghu: check_zero race fix, enum for kvm_contention_stat
 jumplabel related changes ]
 Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
 ---
  arch/x86/include/asm/kvm_para.h |   14 ++
  arch/x86/kernel/kvm.c   |  255 
 +++
  2 files changed, 267 insertions(+), 2 deletions(-)
 
 diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
 index 695399f..427afcb 100644
 --- a/arch/x86/include/asm/kvm_para.h
 +++ b/arch/x86/include/asm/kvm_para.h
 @@ -118,10 +118,20 @@ void kvm_async_pf_task_wait(u32 token);
  void kvm_async_pf_task_wake(u32 token);
  u32 kvm_read_and_reset_pf_reason(void);
  extern void kvm_disable_steal_time(void);
 -#else
 -#define kvm_guest_init() do { } while (0)
 +
 +#ifdef CONFIG_PARAVIRT_SPINLOCKS
 +void __init kvm_spinlock_init(void);
 +#else /* !CONFIG_PARAVIRT_SPINLOCKS */
 +static inline void kvm_spinlock_init(void)
 +{
 +}
 +#endif /* CONFIG_PARAVIRT_SPINLOCKS */
 +
 +#else /* CONFIG_KVM_GUEST */
 +#define kvm_guest_init() do {} while (0)
  #define kvm_async_pf_task_wait(T) do {} while(0)
  #define kvm_async_pf_task_wake(T) do {} while(0)
 +
  static inline u32 kvm_read_and_reset_pf_reason(void)
  {
   return 0;
 diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
 index cd6d9a5..97ade5a 100644
 --- a/arch/x86/kernel/kvm.c
 +++ b/arch/x86/kernel/kvm.c
 @@ -34,6 +34,7 @@
  #include linux/sched.h
  #include linux/slab.h
  #include linux/kprobes.h
 +#include linux/debugfs.h
  #include asm/timer.h
  #include asm/cpu.h
  #include asm/traps.h
 @@ -419,6 +420,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
   WARN_ON(kvm_register_clock(primary cpu clock));
   kvm_guest_cpu_init();
   native_smp_prepare_boot_cpu();
 + kvm_spinlock_init();
  }
  
  static void __cpuinit kvm_guest_cpu_online(void *dummy)
 @@ -523,3 +525,256 @@ static __init int activate_jump_labels(void)
   return 0;
  }
  arch_initcall(activate_jump_labels);
 +
 +/* Kick a cpu by its apicid. Used to wake up a halted vcpu */
 +void kvm_kick_cpu(int cpu)
 +{
 + int apicid;
 +
 + apicid = per_cpu(x86_cpu_to_apicid, cpu);
 + kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
 +}
 +
 +#ifdef CONFIG_PARAVIRT_SPINLOCKS
 +
 +enum kvm_contention_stat {
 + TAKEN_SLOW,
 + TAKEN_SLOW_PICKUP,
 + RELEASED_SLOW,
 + RELEASED_SLOW_KICKED,
 + NR_CONTENTION_STATS
 +};
 +
 +#ifdef CONFIG_KVM_DEBUG_FS
 +#define HISTO_BUCKETS30
 +
 +static struct kvm_spinlock_stats
 +{
 + u32 contention_stats[NR_CONTENTION_STATS];
 + u32 histo_spin_blocked[HISTO_BUCKETS+1];
 + u64 time_blocked;
 +} spinlock_stats;
 +
 +static u8 zero_stats;
 +
 +static inline void check_zero(void)
 +{
 + u8 ret;
 + u8 old;
 +
 + old = ACCESS_ONCE(zero_stats);
 + if (unlikely(old)) {
 + ret = cmpxchg(zero_stats, old, 0);
 + /* This ensures only one fellow resets the stat */
 + if (ret == old)
 + memset(spinlock_stats, 0, sizeof(spinlock_stats));
 + }
 +}
 +
 +static inline void add_stats(enum kvm_contention_stat var, u32 val)
 +{
 + check_zero();
 + spinlock_stats.contention_stats[var] += val;
 +}
 +
 +
 +static inline u64 spin_time_start(void)
 +{
 + return sched_clock();
 +}
 +
 +static void __spin_time_accum(u64 delta, u32 *array)
 +{
 + unsigned index;
 +
 + index = ilog2(delta);
 + check_zero();
 +
 + if (index  HISTO_BUCKETS)
 + array[index]++;
 + else
 + array[HISTO_BUCKETS]++;
 +}
 +
 +static inline void spin_time_accum_blocked(u64 start)
 +{
 + u32 delta;
 +
 + delta = sched_clock() - start;
 + __spin_time_accum(delta, spinlock_stats.histo_spin_blocked);
 + spinlock_stats.time_blocked += delta;
 +}
 +
 +static struct dentry *d_spin_debug;
 +static struct dentry *d_kvm_debug;
 +
 +struct dentry *kvm_init_debugfs(void)
 +{
 + d_kvm_debug = debugfs_create_dir(kvm, NULL);
 + if (!d_kvm_debug)
 + printk(KERN_WARNING Could not create 'kvm' debugfs 
 directory\n);
 +
 + return d_kvm_debug;
 +}
 +
 +static int __init kvm_spinlock_debugfs(void)
 +{
 + struct dentry *d_kvm;
 +
 + d_kvm = kvm_init_debugfs();
 + if (d_kvm == NULL)
 + return -ENOMEM;
 +
 + d_spin_debug = debugfs_create_dir(spinlocks, d_kvm);
 +
 + 

Re: [PATCH RFC V10 16/18] kvm hypervisor : Simplify kvm_for_each_vcpu with kvm_irq_delivery_to_apic

2013-07-14 Thread Gleb Natapov
On Mon, Jun 24, 2013 at 06:13:53PM +0530, Raghavendra K T wrote:
 Simplify kvm_for_each_vcpu with kvm_irq_delivery_to_apic
 
 From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
 
 Note that we are using APIC_DM_REMRD which has reserved usage.
 In future if APIC_DM_REMRD usage is standardized, then we should
 find some other way or go back to old method.
 
 Suggested-by: Gleb Natapov g...@redhat.com
 Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
 ---
  arch/x86/kvm/lapic.c |5 -
  arch/x86/kvm/x86.c   |   25 ++---
  2 files changed, 10 insertions(+), 20 deletions(-)
 
 diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
 index e1adbb4..3f5f82e 100644
 --- a/arch/x86/kvm/lapic.c
 +++ b/arch/x86/kvm/lapic.c
 @@ -706,7 +706,10 @@ out:
   break;
  
   case APIC_DM_REMRD:
 - apic_debug(Ignoring delivery mode 3\n);
 + result = 1;
 + vcpu-arch.pv.pv_unhalted = 1;
 + kvm_make_request(KVM_REQ_EVENT, vcpu);
 + kvm_vcpu_kick(vcpu);
   break;
  
   case APIC_DM_SMI:
 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
 index 92a9932..b963c86 100644
 --- a/arch/x86/kvm/x86.c
 +++ b/arch/x86/kvm/x86.c
 @@ -5456,27 +5456,14 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
   */
  static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
  {
 - struct kvm_vcpu *vcpu = NULL;
 - int i;
 + struct kvm_lapic_irq lapic_irq;
  
 - kvm_for_each_vcpu(i, vcpu, kvm) {
 - if (!kvm_apic_present(vcpu))
 - continue;
 + lapic_irq.shorthand = 0;
 + lapic_irq.dest_mode = 0;
 + lapic_irq.dest_id = apicid;
  
 - if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
 - break;
 - }
 - if (vcpu) {
 - /*
 -  * Setting unhalt flag here can result in spurious runnable
 -  * state when unhalt reset does not happen in vcpu_block.
 -  * But that is harmless since that should soon result in halt.
 -  */
 - vcpu-arch.pv.pv_unhalted = true;
 - /* We need everybody see unhalt before vcpu unblocks */
 - smp_wmb();
 - kvm_vcpu_kick(vcpu);
 - }
 + lapic_irq.delivery_mode = APIC_DM_REMRD;
Need to make sure that delivery_mode cannot be set to APIC_DM_REMRD
from MSI/IOAPIC/IPI path.

 + kvm_irq_delivery_to_apic(kvm, 0, lapic_irq, NULL);
  }
  
  int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)

--
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 RFC V10 12/18] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks

2013-07-14 Thread Gleb Natapov
On Mon, Jun 24, 2013 at 06:13:04PM +0530, Raghavendra K T wrote:
 kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
 
 From: Srivatsa Vaddagiri va...@linux.vnet.ibm.com
 
 kvm_hc_kick_cpu allows the calling vcpu to kick another vcpu out of halt 
 state.
 the presence of these hypercalls is indicated to guest via
 kvm_feature_pv_unhalt.
 
 Signed-off-by: Srivatsa Vaddagiri va...@linux.vnet.ibm.com
 Signed-off-by: Suzuki Poulose suz...@in.ibm.com
 [Raghu: Apic related changes, folding pvunhalted into vcpu_runnable]
 Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
 ---
  arch/x86/include/asm/kvm_host.h  |5 +
  arch/x86/include/uapi/asm/kvm_para.h |1 +
  arch/x86/kvm/cpuid.c |3 ++-
  arch/x86/kvm/x86.c   |   37 
 ++
  include/uapi/linux/kvm_para.h|1 +
  5 files changed, 46 insertions(+), 1 deletion(-)
 
 diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
 index 3741c65..95702de 100644
 --- a/arch/x86/include/asm/kvm_host.h
 +++ b/arch/x86/include/asm/kvm_host.h
 @@ -503,6 +503,11 @@ struct kvm_vcpu_arch {
* instruction.
*/
   bool write_fault_to_shadow_pgtable;
 +
 + /* pv related host specific info */
 + struct {
 + bool pv_unhalted;
 + } pv;
  };
  
  struct kvm_lpage_info {
 diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
 b/arch/x86/include/uapi/asm/kvm_para.h
 index 06fdbd9..94dc8ca 100644
 --- a/arch/x86/include/uapi/asm/kvm_para.h
 +++ b/arch/x86/include/uapi/asm/kvm_para.h
 @@ -23,6 +23,7 @@
  #define KVM_FEATURE_ASYNC_PF 4
  #define KVM_FEATURE_STEAL_TIME   5
  #define KVM_FEATURE_PV_EOI   6
 +#define KVM_FEATURE_PV_UNHALT7
  
  /* The last 8 bits are used to indicate how to interpret the flags field
   * in pvclock structure. If no bits are set, all flags are ignored.
 diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
 index a20ecb5..b110fe6 100644
 --- a/arch/x86/kvm/cpuid.c
 +++ b/arch/x86/kvm/cpuid.c
 @@ -413,7 +413,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, 
 u32 function,
(1  KVM_FEATURE_CLOCKSOURCE2) |
(1  KVM_FEATURE_ASYNC_PF) |
(1  KVM_FEATURE_PV_EOI) |
 -  (1  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
 +  (1  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
 +  (1  KVM_FEATURE_PV_UNHALT);
  
   if (sched_info_on())
   entry-eax |= (1  KVM_FEATURE_STEAL_TIME);
 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
 index 094b5d9..f8bea30 100644
 --- a/arch/x86/kvm/x86.c
 +++ b/arch/x86/kvm/x86.c
 @@ -5449,6 +5449,36 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
   return 1;
  }
  
 +/*
 + * kvm_pv_kick_cpu_op:  Kick a vcpu.
 + *
 + * @apicid - apicid of vcpu to be kicked.
 + */
 +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
 +{
 + struct kvm_vcpu *vcpu = NULL;
 + int i;
 +
 + kvm_for_each_vcpu(i, vcpu, kvm) {
 + if (!kvm_apic_present(vcpu))
 + continue;
 +
 + if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
 + break;
 + }
 + if (vcpu) {
 + /*
 +  * Setting unhalt flag here can result in spurious runnable
 +  * state when unhalt reset does not happen in vcpu_block.
 +  * But that is harmless since that should soon result in halt.
 +  */
 + vcpu-arch.pv.pv_unhalted = true;
 + /* We need everybody see unhalt before vcpu unblocks */
 + smp_wmb();
 + kvm_vcpu_kick(vcpu);
 + }
 +}
 +
  int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
  {
   unsigned long nr, a0, a1, a2, a3, ret;
 @@ -5482,6 +5512,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
   case KVM_HC_VAPIC_POLL_IRQ:
   ret = 0;
   break;
 + case KVM_HC_KICK_CPU:
 + kvm_pv_kick_cpu_op(vcpu-kvm, a0);
Lets make it hypercall with two parameters: 
a0 - flags
a1 - apic id of a cpu to kick

A0 have to be zero. This will make it more extensible.

 + ret = 0;
 + break;
   default:
   ret = -KVM_ENOSYS;
   break;
 @@ -5909,6 +5943,7 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
   kvm_apic_accept_events(vcpu);
   switch(vcpu-arch.mp_state) {
   case KVM_MP_STATE_HALTED:
 + vcpu-arch.pv.pv_unhalted = false;
   vcpu-arch.mp_state =
   KVM_MP_STATE_RUNNABLE;
   case KVM_MP_STATE_RUNNABLE:
 @@ -6729,6 +6764,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
   

Re: [PATCH RFC V10 18/18] kvm hypervisor: Add directed yield in vcpu block path

2013-07-14 Thread Gleb Natapov
On Mon, Jun 24, 2013 at 06:14:15PM +0530, Raghavendra K T wrote:
 kvm hypervisor: Add directed yield in vcpu block path
 
 From: Raghavendra K T raghavendra...@linux.vnet.ibm.com
 
 We use the improved PLE handler logic in vcpu block patch for
 scheduling rather than plain schedule, so that we can make
 intelligent decisions.
 
What kind of improvement this provides? Doesn't it screw up our pause
exit heuristics?

 Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
 ---
  arch/ia64/include/asm/kvm_host.h|5 +
  arch/powerpc/include/asm/kvm_host.h |5 +
  arch/s390/include/asm/kvm_host.h|5 +
  arch/x86/include/asm/kvm_host.h |2 +-
  arch/x86/kvm/x86.c  |8 
  include/linux/kvm_host.h|2 +-
  virt/kvm/kvm_main.c |6 --
This miss some arches.

  7 files changed, 29 insertions(+), 4 deletions(-)
 
 diff --git a/arch/ia64/include/asm/kvm_host.h 
 b/arch/ia64/include/asm/kvm_host.h
 index 989dd3f..999ab15 100644
 --- a/arch/ia64/include/asm/kvm_host.h
 +++ b/arch/ia64/include/asm/kvm_host.h
 @@ -595,6 +595,11 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu);
  int kvm_pal_emul(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run);
  void kvm_sal_emul(struct kvm_vcpu *vcpu);
  
 +static inline void kvm_do_schedule(struct kvm_vcpu *vcpu)
 +{
 + schedule();
 +}
 +
  #define __KVM_HAVE_ARCH_VM_ALLOC 1
  struct kvm *kvm_arch_alloc_vm(void);
  void kvm_arch_free_vm(struct kvm *kvm);
 diff --git a/arch/powerpc/include/asm/kvm_host.h 
 b/arch/powerpc/include/asm/kvm_host.h
 index af326cd..1aeecc0 100644
 --- a/arch/powerpc/include/asm/kvm_host.h
 +++ b/arch/powerpc/include/asm/kvm_host.h
 @@ -628,4 +628,9 @@ struct kvm_vcpu_arch {
  #define __KVM_HAVE_ARCH_WQP
  #define __KVM_HAVE_CREATE_DEVICE
  
 +static inline void kvm_do_schedule(struct kvm_vcpu *vcpu)
 +{
 + schedule();
 +}
 +
  #endif /* __POWERPC_KVM_HOST_H__ */
 diff --git a/arch/s390/include/asm/kvm_host.h 
 b/arch/s390/include/asm/kvm_host.h
 index 16bd5d1..db09a56 100644
 --- a/arch/s390/include/asm/kvm_host.h
 +++ b/arch/s390/include/asm/kvm_host.h
 @@ -266,4 +266,9 @@ struct kvm_arch{
  };
  
  extern int sie64a(struct kvm_s390_sie_block *, u64 *);
 +static inline void kvm_do_schedule(struct kvm_vcpu *vcpu)
 +{
 + schedule();
 +}
 +
  #endif
 diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
 index 95702de..72ff791 100644
 --- a/arch/x86/include/asm/kvm_host.h
 +++ b/arch/x86/include/asm/kvm_host.h
 @@ -1042,5 +1042,5 @@ int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct 
 msr_data *msr_info);
  int kvm_pmu_read_pmc(struct kvm_vcpu *vcpu, unsigned pmc, u64 *data);
  void kvm_handle_pmu_event(struct kvm_vcpu *vcpu);
  void kvm_deliver_pmi(struct kvm_vcpu *vcpu);
 -
 +void kvm_do_schedule(struct kvm_vcpu *vcpu);
  #endif /* _ASM_X86_KVM_HOST_H */
 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
 index b963c86..84a4eb2 100644
 --- a/arch/x86/kvm/x86.c
 +++ b/arch/x86/kvm/x86.c
 @@ -7281,6 +7281,14 @@ bool kvm_arch_can_inject_async_page_present(struct 
 kvm_vcpu *vcpu)
   kvm_x86_ops-interrupt_allowed(vcpu);
  }
  
 +void kvm_do_schedule(struct kvm_vcpu *vcpu)
 +{
 + /* We try to yield to a kicked vcpu else do a schedule */
 + if (kvm_vcpu_on_spin(vcpu) = 0)
 + schedule();
 +}
 +EXPORT_SYMBOL_GPL(kvm_do_schedule);
 +
  EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_exit);
  EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
  EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_page_fault);
 diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
 index f0eea07..39efc18 100644
 --- a/include/linux/kvm_host.h
 +++ b/include/linux/kvm_host.h
 @@ -565,7 +565,7 @@ void mark_page_dirty_in_slot(struct kvm *kvm, struct 
 kvm_memory_slot *memslot,
  void kvm_vcpu_block(struct kvm_vcpu *vcpu);
  void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
  bool kvm_vcpu_yield_to(struct kvm_vcpu *target);
 -void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu);
 +bool kvm_vcpu_on_spin(struct kvm_vcpu *vcpu);
  void kvm_resched(struct kvm_vcpu *vcpu);
  void kvm_load_guest_fpu(struct kvm_vcpu *vcpu);
  void kvm_put_guest_fpu(struct kvm_vcpu *vcpu);
 diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
 index 302681c..8387247 100644
 --- a/virt/kvm/kvm_main.c
 +++ b/virt/kvm/kvm_main.c
 @@ -1685,7 +1685,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
   if (signal_pending(current))
   break;
  
 - schedule();
 + kvm_do_schedule(vcpu);
   }
  
   finish_wait(vcpu-wq, wait);
 @@ -1786,7 +1786,7 @@ bool kvm_vcpu_eligible_for_directed_yield(struct 
 kvm_vcpu *vcpu)
  }
  #endif
  
 -void kvm_vcpu_on_spin(struct kvm_vcpu *me)
 +bool kvm_vcpu_on_spin(struct kvm_vcpu *me)
  {
   struct kvm *kvm = me-kvm;
   struct kvm_vcpu *vcpu;
 @@ -1835,6 +1835,8 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
  
   /* Ensure vcpu is not eligible during next spinloop */
   

Re: Call for Proposals: 2013 Linux Plumbers Virtualization Microconference

2013-07-14 Thread Alex Williamson
On Fri, 2013-07-12 at 14:38 -0600, Alex Williamson wrote:
 The Call for Proposals for the 2013 Linux Plumbers Virtualization
 Microconference is now open.  This uconf is being held as part of Linux
 Plumbers Conference in New Orleans, Louisiana, USA September 18-20th and
 is co-located with LinuxCon North America.  For more information see:
 
 http://www.linuxplumbersconf.org/2013/
 
 The tentative deadline for proposals is August 1st.  To submit a topic
 please email a brief abstract to lpc2013-virt...@codemonkey.ws  If you
 require travel assistance (extremely limited) in order to attend, please
 note that in your submission.  Also, please keep an eye on:
 
 http://www.linuxplumbersconf.org/2013/submitting-topic/
 http://www.linuxplumbersconf.org/2013/participate/
 
 We've setup the above email submission as an interim approach until the
 LPC program committee brings the official submission tool online.  I'll
 send a follow-up message when that occurs, but please send your
 proposals as soon as possible.  Thanks,

And the official tool is now online.  Please see:

http://www.linuxplumbersconf.org/2013/microconference-discussion-topic-bof-submissions-now-open/

for instructions to propose a discussion topic for the virtualization
microconference.  Thanks,

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


Re: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()

2013-07-14 Thread tiejun.chen

On 07/13/2013 07:05 AM, Benjamin Herrenschmidt wrote:

On Fri, 2013-07-12 at 12:50 -0500, Scott Wood wrote:


[1] SOFT_DISABLE_INTS seems an odd name for something that updates the
software state to be consistent with interrupts being *hard* disabled.
I can sort of see the logic in it, but it's confusing when first
encountered.  From the name it looks like all it would do is set
soft_enabled to 1.


It's indeed odd. Also worse when we use DISABLE_INTS which is just a
macro on top of SOFT_DISABLE_INTS :-)

I've been wanting to change the macro name for a while now and never
got to it. Patch welcome :-)



What about SOFT_IRQ_DISABLE? This is close to name hard_irq_disable() :) And 
then remove all DISABLE_INTS as well?


Tiejun

--
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: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()

2013-07-14 Thread tiejun.chen

On 07/13/2013 01:50 AM, Scott Wood wrote:

On 07/11/2013 10:22:28 PM, tiejun.chen wrote:

If so, why not to remove directly hard_irq_disable() inside
kvmppc_handle_exit() by reverting that commit, kvm/ppc/booke64: Fix lazy ee
handling in kvmppc_handle_exit()?

Then we can use SOFT_DISABLE_INTS() explicitly before call
kvmppc_handle_exit() like this:

KVM: PPC: Book3E HV: call SOFT_DISABLE_INTS to sync the software state

We enter with interrupts disabled in hardware, but we need to
call SOFT_DISABLE_INTS anyway to ensure that the software state
is kept in sync.

Signed-off-by: Tiejun Chen tiejun.c...@windriver.com

diff --git a/arch/powerpc/kvm/bookehv_interrupts.S
b/arch/powerpc/kvm/bookehv_interrupts.S
index e8ed7d6..b521d21 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -33,6 +33,8 @@

 #ifdef CONFIG_64BIT
 #include asm/exception-64e.h
+#include asm/hw_irq.h
+#include asm/irqflags.h
 #else
 #include ../kernel/head_booke.h /* for THREAD_NORMSAVE() */
 #endif
@@ -469,6 +471,14 @@ _GLOBAL(kvmppc_resume_host)
PPC_LL  r3, HOST_RUN(r1)
mr  r5, r14 /* intno */
mr  r14, r4 /* Save vcpu pointer. */
+#ifdef CONFIG_64BIT
+   /*
+* We enter with interrupts disabled in hardware, but
+* we need to call SOFT_DISABLE_INTS anyway to ensure
+* that the software state is kept in sync.
+*/
+   SOFT_DISABLE_INTS(r7,r8)
+#endif

bl  kvmppc_handle_exit


This will clobber the arguments we want to pass to kvmppc_handle_exit.  That can
be fixed by moving SOFT_DISABLE_INTS[1] earlier, and maybe it's more idiomatic


Okay. Once we have a final name to replace SOFT_DISABLE_INTS, I can regenerate 
this as you comment.



to use SOFT_DISABLE_INTS rather than what we currently do, but we still want to
fix hard_irq_disable().  There are other places where we call hard_irq_disable()
where interrupts (and I believe preemption) were previously enabled.


Yes, I had a preliminary change ACKed by Ben, and I guess you also saw :) so 
I'll send that firstly.


Thanks,

Tiejun
--
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


[v1][PATCH 1/1] powerpc: to access local paca after hard irq disabled

2013-07-14 Thread Tiejun Chen
We can access paca directly after hard interrupt disabled, and
this can avoid accessing wrong paca when using get_paca() in
preempt case.

Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
 arch/powerpc/include/asm/hw_irq.h |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/hw_irq.h 
b/arch/powerpc/include/asm/hw_irq.h
index ba713f1..10be1dd 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -96,10 +96,11 @@ static inline bool arch_irqs_disabled(void)
 #endif
 
 #define hard_irq_disable() do {\
-   u8 _was_enabled = get_paca()-soft_enabled; \
+   u8 _was_enabled;\
__hard_irq_disable();   \
-   get_paca()-soft_enabled = 0;   \
-   get_paca()-irq_happened |= PACA_IRQ_HARD_DIS;  \
+   _was_enabled = local_paca-soft_enabled;\
+   local_paca-soft_enabled = 0;   \
+   local_paca-irq_happened |= PACA_IRQ_HARD_DIS;  \
if (_was_enabled)   \
trace_hardirqs_off();   \
 } while(0)
-- 
1.7.9.5

--
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: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()

2013-07-14 Thread Benjamin Herrenschmidt
On Mon, 2013-07-15 at 10:20 +0800, tiejun.chen wrote:
 What about SOFT_IRQ_DISABLE? This is close to name
 hard_irq_disable() :) And 
 then remove all DISABLE_INTS as well?

Or RECONCILE_IRQ_STATE...

Ben.


--
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: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()

2013-07-14 Thread tiejun.chen

On 07/15/2013 10:47 AM, Benjamin Herrenschmidt wrote:

On Mon, 2013-07-15 at 10:20 +0800, tiejun.chen wrote:

What about SOFT_IRQ_DISABLE? This is close to name
hard_irq_disable() :) And
then remove all DISABLE_INTS as well?


Or RECONCILE_IRQ_STATE...


But sounds this doesn't imply this key point that the soft-irq is always 
disabled here :)


And as I understand, the irq state is always needed to be reconciled when we 
disable soft irq, right?


Tiejun
--
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: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()

2013-07-14 Thread tiejun.chen

On 07/14/2013 12:13 PM, Benjamin Herrenschmidt wrote:

On Fri, 2013-07-12 at 12:54 +0800, tiejun.chen wrote:

Is the following fine?

powerpc: to access local paca after hard irq disabled

We can access paca directly after hard interrupt disabled, and
this can avoid accessing wrong paca when using get_paca() in
preempt case.

Signed-off-by: Tiejun Chen tiejun.c...@windriver.com


Ack. We still have an unresolved problem where gcc decides to copy r13
to another register and then index from that, or even store and reload
it, and this possibly accross preempt sections.

It's unclear to me in what circumstances it will do it and whether
there's a case of us getting completely screwed over, I need to
investigate. This is the reason why we originally made the accesses to
soft_enabled be inline asm.


Understood.



We might need to do a bulk conversion of all PACA accesses to either
such inline asm or hide r13 behind asm (forcing essentially a copy
to another register on each use) or a combination of both.

IE. inline asm for direct access of things like soft_enabled, and a
get_paca/put_paca style interface that copies r13 and includes a
preempt_disable/enable for the rest.



I'd like to check this possibility later.

Tiejun

--
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: AMD integrated graphics passthrough to KVM guest

2013-07-14 Thread Alex Williamson
On Sat, 2013-07-13 at 21:45 +0200, Gustav Sorenson wrote:
 Hello Alex,
 
 I'm thinking about buying a HD 7850 to go with my integrated graphics
 card, so that I can pass the 7850 to a KVM guest and keep the
 integrated GPU for the host. However, I'd like to use the proprietary
 AMD drivers for the host to get reasonable 3D performance there (the
 open source driver that ships with Mint 15 didn't get me far; maybe it
 should and I've done something wrong?). I've read here:
 https://bbs.archlinux.org/viewtopic.php?pid=1273412#p1273412
 that this scenario caused problems. Is this still the case?

That's actually the first I've heard of that problem.  I don't see why
it wouldn't still be the case, fglrx is broken if that report is
accurate.

 Which GPU do you use on the host / guest, and which driver combinations work?

I'm not a good example, I don't do anything on the host VGA at all.

 Or should I just grab an nVidia instead?

If you plan to run fglrx in the host, it would certainly help to work
around the above issue, but I don't have much direct experience with
anything newer than an 8400GS.

 Of course I'd be happy to hear reports from others as well. :)

Yep, I'm astonished at the number of users trying to make this work.
I'm sure someone has some knowledge they can share.  Thanks,

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


Re: [[Qemu-devel] [PATCH]] nVMX: Initialize IA32_FEATURE_CONTROL MSR in reset and migration

2013-07-14 Thread Arthur Chunqi Li
Hi Gleb and Paolo,
What is the status of this patch since the relevant patch for KVM is
accepted? These two patches must cooperate to fix the bug.

Arthur

On Sun, Jul 7, 2013 at 11:13 PM, Arthur Chunqi Li yzt...@gmail.com wrote:
 The recent KVM patch adds IA32_FEATURE_CONTROL support. QEMU needs
 to clear this MSR when reset vCPU and keep the value of it when
 migration. This patch add this feature.

 Signed-off-by: Arthur Chunqi Li yzt...@gmail.com
 ---
  target-i386/cpu.h |2 ++
  target-i386/kvm.c |4 
  target-i386/machine.c |   22 ++
  3 files changed, 28 insertions(+)

 diff --git a/target-i386/cpu.h b/target-i386/cpu.h
 index 62e3547..a418e17 100644
 --- a/target-i386/cpu.h
 +++ b/target-i386/cpu.h
 @@ -301,6 +301,7 @@
  #define MSR_IA32_APICBASE_BSP   (18)
  #define MSR_IA32_APICBASE_ENABLE(111)
  #define MSR_IA32_APICBASE_BASE  (0xf12)
 +#define MSR_IA32_FEATURE_CONTROL0x003a
  #define MSR_TSC_ADJUST  0x003b
  #define MSR_IA32_TSCDEADLINE0x6e0

 @@ -813,6 +814,7 @@ typedef struct CPUX86State {

  uint64_t mcg_status;
  uint64_t msr_ia32_misc_enable;
 +uint64_t msr_ia32_feature_control;

  /* exception/interrupt handling */
  int error_code;
 diff --git a/target-i386/kvm.c b/target-i386/kvm.c
 index 39f4fbb..3cb2161 100644
 --- a/target-i386/kvm.c
 +++ b/target-i386/kvm.c
 @@ -1122,6 +1122,7 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
  if (hyperv_vapic_recommended()) {
  kvm_msr_entry_set(msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
  }
 +kvm_msr_entry_set(msrs[n++], MSR_IA32_FEATURE_CONTROL, 
 env-msr_ia32_feature_control);
  }
  if (env-mcg_cap) {
  int i;
 @@ -1346,6 +1347,7 @@ static int kvm_get_msrs(X86CPU *cpu)
  if (has_msr_misc_enable) {
  msrs[n++].index = MSR_IA32_MISC_ENABLE;
  }
 +msrs[n++].index = MSR_IA32_FEATURE_CONTROL;

  if (!env-tsc_valid) {
  msrs[n++].index = MSR_IA32_TSC;
 @@ -1444,6 +1446,8 @@ static int kvm_get_msrs(X86CPU *cpu)
  case MSR_IA32_MISC_ENABLE:
  env-msr_ia32_misc_enable = msrs[i].data;
  break;
 +case MSR_IA32_FEATURE_CONTROL:
 +env-msr_ia32_feature_control = msrs[i].data;
  default:
  if (msrs[i].index = MSR_MC0_CTL 
  msrs[i].index  MSR_MC0_CTL + (env-mcg_cap  0xff) * 4) {
 diff --git a/target-i386/machine.c b/target-i386/machine.c
 index 3659db9..94ca914 100644
 --- a/target-i386/machine.c
 +++ b/target-i386/machine.c
 @@ -399,6 +399,14 @@ static bool misc_enable_needed(void *opaque)
  return env-msr_ia32_misc_enable != MSR_IA32_MISC_ENABLE_DEFAULT;
  }

 +static bool feature_control_needed(void *opaque)
 +{
 +X86CPU *cpu = opaque;
 +CPUX86State *env = cpu-env;
 +
 +return env-msr_ia32_feature_control != 0;
 +}
 +
  static const VMStateDescription vmstate_msr_ia32_misc_enable = {
  .name = cpu/msr_ia32_misc_enable,
  .version_id = 1,
 @@ -410,6 +418,17 @@ static const VMStateDescription 
 vmstate_msr_ia32_misc_enable = {
  }
  };

 +static const VMStateDescription vmstate_msr_ia32_feature_control = {
 +.name = cpu/msr_ia32_feature_control,
 +.version_id = 1,
 +.minimum_version_id = 1,
 +.minimum_version_id_old = 1,
 +.fields  = (VMStateField []) {
 +VMSTATE_UINT64(env.msr_ia32_feature_control, X86CPU),
 +VMSTATE_END_OF_LIST()
 +}
 +};
 +
  const VMStateDescription vmstate_x86_cpu = {
  .name = cpu,
  .version_id = 12,
 @@ -535,6 +554,9 @@ const VMStateDescription vmstate_x86_cpu = {
  }, {
  .vmsd = vmstate_msr_ia32_misc_enable,
  .needed = misc_enable_needed,
 +}, {
 +.vmsd = vmstate_msr_ia32_feature_control,
 +.needed = feature_control_needed,
  } , {
  /* empty */
  }
 --
 1.7.9.5

--
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 RFC V10 12/18] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks

2013-07-14 Thread Raghavendra K T

On 07/14/2013 07:18 PM, Gleb Natapov wrote:

On Mon, Jun 24, 2013 at 06:13:04PM +0530, Raghavendra K T wrote:

kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks

From: Srivatsa Vaddagiri va...@linux.vnet.ibm.com

kvm_hc_kick_cpu allows the calling vcpu to kick another vcpu out of halt state.
the presence of these hypercalls is indicated to guest via
kvm_feature_pv_unhalt.

Signed-off-by: Srivatsa Vaddagiri va...@linux.vnet.ibm.com
Signed-off-by: Suzuki Poulose suz...@in.ibm.com
[Raghu: Apic related changes, folding pvunhalted into vcpu_runnable]
Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
---
  arch/x86/include/asm/kvm_host.h  |5 +
  arch/x86/include/uapi/asm/kvm_para.h |1 +
  arch/x86/kvm/cpuid.c |3 ++-
  arch/x86/kvm/x86.c   |   37 ++
  include/uapi/linux/kvm_para.h|1 +
  5 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3741c65..95702de 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -503,6 +503,11 @@ struct kvm_vcpu_arch {
 * instruction.
 */
bool write_fault_to_shadow_pgtable;
+
+   /* pv related host specific info */
+   struct {
+   bool pv_unhalted;
+   } pv;
  };

  struct kvm_lpage_info {
diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
b/arch/x86/include/uapi/asm/kvm_para.h
index 06fdbd9..94dc8ca 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -23,6 +23,7 @@
  #define KVM_FEATURE_ASYNC_PF  4
  #define KVM_FEATURE_STEAL_TIME5
  #define KVM_FEATURE_PV_EOI6
+#define KVM_FEATURE_PV_UNHALT  7

  /* The last 8 bits are used to indicate how to interpret the flags field
   * in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index a20ecb5..b110fe6 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -413,7 +413,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 
function,
 (1  KVM_FEATURE_CLOCKSOURCE2) |
 (1  KVM_FEATURE_ASYNC_PF) |
 (1  KVM_FEATURE_PV_EOI) |
-(1  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
+(1  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
+(1  KVM_FEATURE_PV_UNHALT);

if (sched_info_on())
entry-eax |= (1  KVM_FEATURE_STEAL_TIME);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 094b5d9..f8bea30 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5449,6 +5449,36 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
return 1;
  }

+/*
+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
+ *
+ * @apicid - apicid of vcpu to be kicked.
+ */
+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
+{
+   struct kvm_vcpu *vcpu = NULL;
+   int i;
+
+   kvm_for_each_vcpu(i, vcpu, kvm) {
+   if (!kvm_apic_present(vcpu))
+   continue;
+
+   if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
+   break;
+   }
+   if (vcpu) {
+   /*
+* Setting unhalt flag here can result in spurious runnable
+* state when unhalt reset does not happen in vcpu_block.
+* But that is harmless since that should soon result in halt.
+*/
+   vcpu-arch.pv.pv_unhalted = true;
+   /* We need everybody see unhalt before vcpu unblocks */
+   smp_wmb();
+   kvm_vcpu_kick(vcpu);
+   }
+}
+
  int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
  {
unsigned long nr, a0, a1, a2, a3, ret;
@@ -5482,6 +5512,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
case KVM_HC_VAPIC_POLL_IRQ:
ret = 0;
break;
+   case KVM_HC_KICK_CPU:
+   kvm_pv_kick_cpu_op(vcpu-kvm, a0);

Lets make it hypercall with two parameters:
a0 - flags
a1 - apic id of a cpu to kick

A0 have to be zero. This will make it more extensible.


Good point. 'll incorporate that.


--
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: [[Qemu-devel] [PATCH]] nVMX: Initialize IA32_FEATURE_CONTROL MSR in reset and migration

2013-07-14 Thread Gleb Natapov
On Mon, Jul 15, 2013 at 01:44:01PM +0800, Arthur Chunqi Li wrote:
 Hi Gleb and Paolo,
 What is the status of this patch since the relevant patch for KVM is
 accepted? These two patches must cooperate to fix the bug.
 
Need some reviews from migration and machine type experts. Copying Juan
and Eduardo.

 Arthur
 
 On Sun, Jul 7, 2013 at 11:13 PM, Arthur Chunqi Li yzt...@gmail.com wrote:
  The recent KVM patch adds IA32_FEATURE_CONTROL support. QEMU needs
  to clear this MSR when reset vCPU and keep the value of it when
  migration. This patch add this feature.
 
  Signed-off-by: Arthur Chunqi Li yzt...@gmail.com
  ---
   target-i386/cpu.h |2 ++
   target-i386/kvm.c |4 
   target-i386/machine.c |   22 ++
   3 files changed, 28 insertions(+)
 
  diff --git a/target-i386/cpu.h b/target-i386/cpu.h
  index 62e3547..a418e17 100644
  --- a/target-i386/cpu.h
  +++ b/target-i386/cpu.h
  @@ -301,6 +301,7 @@
   #define MSR_IA32_APICBASE_BSP   (18)
   #define MSR_IA32_APICBASE_ENABLE(111)
   #define MSR_IA32_APICBASE_BASE  (0xf12)
  +#define MSR_IA32_FEATURE_CONTROL0x003a
   #define MSR_TSC_ADJUST  0x003b
   #define MSR_IA32_TSCDEADLINE0x6e0
 
  @@ -813,6 +814,7 @@ typedef struct CPUX86State {
 
   uint64_t mcg_status;
   uint64_t msr_ia32_misc_enable;
  +uint64_t msr_ia32_feature_control;
 
   /* exception/interrupt handling */
   int error_code;
  diff --git a/target-i386/kvm.c b/target-i386/kvm.c
  index 39f4fbb..3cb2161 100644
  --- a/target-i386/kvm.c
  +++ b/target-i386/kvm.c
  @@ -1122,6 +1122,7 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
   if (hyperv_vapic_recommended()) {
   kvm_msr_entry_set(msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
   }
  +kvm_msr_entry_set(msrs[n++], MSR_IA32_FEATURE_CONTROL, 
  env-msr_ia32_feature_control);
   }
   if (env-mcg_cap) {
   int i;
  @@ -1346,6 +1347,7 @@ static int kvm_get_msrs(X86CPU *cpu)
   if (has_msr_misc_enable) {
   msrs[n++].index = MSR_IA32_MISC_ENABLE;
   }
  +msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
 
   if (!env-tsc_valid) {
   msrs[n++].index = MSR_IA32_TSC;
  @@ -1444,6 +1446,8 @@ static int kvm_get_msrs(X86CPU *cpu)
   case MSR_IA32_MISC_ENABLE:
   env-msr_ia32_misc_enable = msrs[i].data;
   break;
  +case MSR_IA32_FEATURE_CONTROL:
  +env-msr_ia32_feature_control = msrs[i].data;
   default:
   if (msrs[i].index = MSR_MC0_CTL 
   msrs[i].index  MSR_MC0_CTL + (env-mcg_cap  0xff) * 4) {
  diff --git a/target-i386/machine.c b/target-i386/machine.c
  index 3659db9..94ca914 100644
  --- a/target-i386/machine.c
  +++ b/target-i386/machine.c
  @@ -399,6 +399,14 @@ static bool misc_enable_needed(void *opaque)
   return env-msr_ia32_misc_enable != MSR_IA32_MISC_ENABLE_DEFAULT;
   }
 
  +static bool feature_control_needed(void *opaque)
  +{
  +X86CPU *cpu = opaque;
  +CPUX86State *env = cpu-env;
  +
  +return env-msr_ia32_feature_control != 0;
  +}
  +
   static const VMStateDescription vmstate_msr_ia32_misc_enable = {
   .name = cpu/msr_ia32_misc_enable,
   .version_id = 1,
  @@ -410,6 +418,17 @@ static const VMStateDescription 
  vmstate_msr_ia32_misc_enable = {
   }
   };
 
  +static const VMStateDescription vmstate_msr_ia32_feature_control = {
  +.name = cpu/msr_ia32_feature_control,
  +.version_id = 1,
  +.minimum_version_id = 1,
  +.minimum_version_id_old = 1,
  +.fields  = (VMStateField []) {
  +VMSTATE_UINT64(env.msr_ia32_feature_control, X86CPU),
  +VMSTATE_END_OF_LIST()
  +}
  +};
  +
   const VMStateDescription vmstate_x86_cpu = {
   .name = cpu,
   .version_id = 12,
  @@ -535,6 +554,9 @@ const VMStateDescription vmstate_x86_cpu = {
   }, {
   .vmsd = vmstate_msr_ia32_misc_enable,
   .needed = misc_enable_needed,
  +}, {
  +.vmsd = vmstate_msr_ia32_feature_control,
  +.needed = feature_control_needed,
   } , {
   /* empty */
   }
  --
  1.7.9.5
 

--
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: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()

2013-07-14 Thread tiejun.chen

On 07/13/2013 07:05 AM, Benjamin Herrenschmidt wrote:

On Fri, 2013-07-12 at 12:50 -0500, Scott Wood wrote:


[1] SOFT_DISABLE_INTS seems an odd name for something that updates the
software state to be consistent with interrupts being *hard* disabled.
I can sort of see the logic in it, but it's confusing when first
encountered.  From the name it looks like all it would do is set
soft_enabled to 1.


It's indeed odd. Also worse when we use DISABLE_INTS which is just a
macro on top of SOFT_DISABLE_INTS :-)

I've been wanting to change the macro name for a while now and never
got to it. Patch welcome :-)



What about SOFT_IRQ_DISABLE? This is close to name hard_irq_disable() :) And 
then remove all DISABLE_INTS as well?


Tiejun

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


Re: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()

2013-07-14 Thread tiejun.chen

On 07/13/2013 01:50 AM, Scott Wood wrote:

On 07/11/2013 10:22:28 PM, tiejun.chen wrote:

If so, why not to remove directly hard_irq_disable() inside
kvmppc_handle_exit() by reverting that commit, kvm/ppc/booke64: Fix lazy ee
handling in kvmppc_handle_exit()?

Then we can use SOFT_DISABLE_INTS() explicitly before call
kvmppc_handle_exit() like this:

KVM: PPC: Book3E HV: call SOFT_DISABLE_INTS to sync the software state

We enter with interrupts disabled in hardware, but we need to
call SOFT_DISABLE_INTS anyway to ensure that the software state
is kept in sync.

Signed-off-by: Tiejun Chen tiejun.c...@windriver.com

diff --git a/arch/powerpc/kvm/bookehv_interrupts.S
b/arch/powerpc/kvm/bookehv_interrupts.S
index e8ed7d6..b521d21 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -33,6 +33,8 @@

 #ifdef CONFIG_64BIT
 #include asm/exception-64e.h
+#include asm/hw_irq.h
+#include asm/irqflags.h
 #else
 #include ../kernel/head_booke.h /* for THREAD_NORMSAVE() */
 #endif
@@ -469,6 +471,14 @@ _GLOBAL(kvmppc_resume_host)
PPC_LL  r3, HOST_RUN(r1)
mr  r5, r14 /* intno */
mr  r14, r4 /* Save vcpu pointer. */
+#ifdef CONFIG_64BIT
+   /*
+* We enter with interrupts disabled in hardware, but
+* we need to call SOFT_DISABLE_INTS anyway to ensure
+* that the software state is kept in sync.
+*/
+   SOFT_DISABLE_INTS(r7,r8)
+#endif

bl  kvmppc_handle_exit


This will clobber the arguments we want to pass to kvmppc_handle_exit.  That can
be fixed by moving SOFT_DISABLE_INTS[1] earlier, and maybe it's more idiomatic


Okay. Once we have a final name to replace SOFT_DISABLE_INTS, I can regenerate 
this as you comment.



to use SOFT_DISABLE_INTS rather than what we currently do, but we still want to
fix hard_irq_disable().  There are other places where we call hard_irq_disable()
where interrupts (and I believe preemption) were previously enabled.


Yes, I had a preliminary change ACKed by Ben, and I guess you also saw :) so 
I'll send that firstly.


Thanks,

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


[v1][PATCH 1/1] powerpc: to access local paca after hard irq disabled

2013-07-14 Thread Tiejun Chen
We can access paca directly after hard interrupt disabled, and
this can avoid accessing wrong paca when using get_paca() in
preempt case.

Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
 arch/powerpc/include/asm/hw_irq.h |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/hw_irq.h 
b/arch/powerpc/include/asm/hw_irq.h
index ba713f1..10be1dd 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -96,10 +96,11 @@ static inline bool arch_irqs_disabled(void)
 #endif
 
 #define hard_irq_disable() do {\
-   u8 _was_enabled = get_paca()-soft_enabled; \
+   u8 _was_enabled;\
__hard_irq_disable();   \
-   get_paca()-soft_enabled = 0;   \
-   get_paca()-irq_happened |= PACA_IRQ_HARD_DIS;  \
+   _was_enabled = local_paca-soft_enabled;\
+   local_paca-soft_enabled = 0;   \
+   local_paca-irq_happened |= PACA_IRQ_HARD_DIS;  \
if (_was_enabled)   \
trace_hardirqs_off();   \
 } while(0)
-- 
1.7.9.5

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


Re: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()

2013-07-14 Thread Benjamin Herrenschmidt
On Mon, 2013-07-15 at 10:20 +0800, tiejun.chen wrote:
 What about SOFT_IRQ_DISABLE? This is close to name
 hard_irq_disable() :) And 
 then remove all DISABLE_INTS as well?

Or RECONCILE_IRQ_STATE...

Ben.


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


Re: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()

2013-07-14 Thread tiejun.chen

On 07/14/2013 12:13 PM, Benjamin Herrenschmidt wrote:

On Fri, 2013-07-12 at 12:54 +0800, tiejun.chen wrote:

Is the following fine?

powerpc: to access local paca after hard irq disabled

We can access paca directly after hard interrupt disabled, and
this can avoid accessing wrong paca when using get_paca() in
preempt case.

Signed-off-by: Tiejun Chen tiejun.c...@windriver.com


Ack. We still have an unresolved problem where gcc decides to copy r13
to another register and then index from that, or even store and reload
it, and this possibly accross preempt sections.

It's unclear to me in what circumstances it will do it and whether
there's a case of us getting completely screwed over, I need to
investigate. This is the reason why we originally made the accesses to
soft_enabled be inline asm.


Understood.



We might need to do a bulk conversion of all PACA accesses to either
such inline asm or hide r13 behind asm (forcing essentially a copy
to another register on each use) or a combination of both.

IE. inline asm for direct access of things like soft_enabled, and a
get_paca/put_paca style interface that copies r13 and includes a
preempt_disable/enable for the rest.



I'd like to check this possibility later.

Tiejun

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


Re: [v1][PATCH 1/1] KVM: PPC: disable preemption when using hard_irq_disable()

2013-07-14 Thread tiejun.chen

On 07/15/2013 10:47 AM, Benjamin Herrenschmidt wrote:

On Mon, 2013-07-15 at 10:20 +0800, tiejun.chen wrote:

What about SOFT_IRQ_DISABLE? This is close to name
hard_irq_disable() :) And
then remove all DISABLE_INTS as well?


Or RECONCILE_IRQ_STATE...


But sounds this doesn't imply this key point that the soft-irq is always 
disabled here :)


And as I understand, the irq state is always needed to be reconciled when we 
disable soft irq, right?


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