Re: Process blocked for more than 120 seconds.

[Stefan Hajnoczi]

On Wed, Dec 12, 2012 at 1:01 PM, Andrew Holway a.hol...@syseleven.de wrote:
 No the NFS is not hung and yes I can access the image on the host.

 Its just seems to happen occasionally with some VMs..

Not sure how to approach this besides looking at Linux and QEMU
sources and deciding what to trace/debug, sorry.

Stefan
--
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: Don't use vcpu-requests for steal time accounting

[Takuya Yoshikawa]

We can check if accum_steal has any positive value instead of using
KVM_REQ_STEAL_UPDATE bit in vcpu-requests; and this is the way we
usually do for accounting for something in the kernel.

Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
 arch/x86/kvm/x86.c   |   11 +--
 include/linux/kvm_host.h |   41 -
 2 files changed, 25 insertions(+), 27 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 57c76e8..fab4c3e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1857,6 +1857,9 @@ static void accumulate_steal_time(struct kvm_vcpu *vcpu)
 
 static void record_steal_time(struct kvm_vcpu *vcpu)
 {
+   if (!vcpu-arch.st.accum_steal)
+   return;
+
if (!(vcpu-arch.st.msr_val  KVM_MSR_ENABLED))
return;
 
@@ -1992,9 +1995,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
preempt_disable();
accumulate_steal_time(vcpu);
preempt_enable();
-
-   kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
-
break;
case MSR_KVM_PV_EOI_EN:
if (kvm_lapic_enable_pv_eoi(vcpu, data))
@@ -2668,7 +2668,6 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
}
 
accumulate_steal_time(vcpu);
-   kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
 }
 
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
@@ -5645,8 +5644,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
r = 1;
goto out;
}
-   if (kvm_check_request(KVM_REQ_STEAL_UPDATE, vcpu))
-   record_steal_time(vcpu);
if (kvm_check_request(KVM_REQ_NMI, vcpu))
process_nmi(vcpu);
req_immediate_exit =
@@ -5672,6 +5669,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
}
}
 
+   record_steal_time(vcpu);
+
r = kvm_mmu_reload(vcpu);
if (unlikely(r)) {
goto cancel_injection;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 91ae127..5476ffc 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -112,27 +112,26 @@ static inline bool is_error_page(struct page *page)
 /*
  * vcpu-requests bit members
  */
-#define KVM_REQ_TLB_FLUSH  0
-#define KVM_REQ_MIGRATE_TIMER  1
-#define KVM_REQ_REPORT_TPR_ACCESS  2
-#define KVM_REQ_MMU_RELOAD 3
-#define KVM_REQ_TRIPLE_FAULT   4
-#define KVM_REQ_PENDING_TIMER  5
-#define KVM_REQ_UNHALT 6
-#define KVM_REQ_MMU_SYNC   7
-#define KVM_REQ_CLOCK_UPDATE   8
-#define KVM_REQ_KICK   9
-#define KVM_REQ_DEACTIVATE_FPU10
-#define KVM_REQ_EVENT 11
-#define KVM_REQ_APF_HALT  12
-#define KVM_REQ_STEAL_UPDATE  13
-#define KVM_REQ_NMI   14
-#define KVM_REQ_IMMEDIATE_EXIT15
-#define KVM_REQ_PMU   16
-#define KVM_REQ_PMI   17
-#define KVM_REQ_WATCHDOG  18
-#define KVM_REQ_MASTERCLOCK_UPDATE 19
-#define KVM_REQ_MCLOCK_INPROGRESS 20
+#define KVM_REQ_TLB_FLUSH  0
+#define KVM_REQ_MIGRATE_TIMER  1
+#define KVM_REQ_REPORT_TPR_ACCESS  2
+#define KVM_REQ_MMU_RELOAD 3
+#define KVM_REQ_TRIPLE_FAULT   4
+#define KVM_REQ_PENDING_TIMER  5
+#define KVM_REQ_UNHALT 6
+#define KVM_REQ_MMU_SYNC   7
+#define KVM_REQ_CLOCK_UPDATE   8
+#define KVM_REQ_KICK   9
+#define KVM_REQ_DEACTIVATE_FPU 10
+#define KVM_REQ_EVENT  11
+#define KVM_REQ_APF_HALT   12
+#define KVM_REQ_NMI13
+#define KVM_REQ_IMMEDIATE_EXIT 14
+#define KVM_REQ_PMU15
+#define KVM_REQ_PMI16
+#define KVM_REQ_WATCHDOG   17
+#define KVM_REQ_MASTERCLOCK_UPDATE 18
+#define KVM_REQ_MCLOCK_INPROGRESS  19
 
 #define KVM_USERSPACE_IRQ_SOURCE_ID0
 #define KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID   1
-- 
1.7.5.4

--
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: emulator: implement AAD instruction

[Paolo Bonzini]

Il 10/12/2012 10:42, Gleb Natapov ha scritto:
 Windows2000 uses it during boot. This fixes
 https://bugzilla.kernel.org/show_bug.cgi?id=50921
 
 Signed-off-by: Gleb Natapov g...@redhat.com
 diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
 index 39171cb..92c7292 100644
 --- a/arch/x86/kvm/emulate.c
 +++ b/arch/x86/kvm/emulate.c
 @@ -2852,6 +2852,27 @@ static int em_das(struct x86_emulate_ctxt *ctxt)
   return X86EMUL_CONTINUE;
  }
  
 +static int em_aad(struct x86_emulate_ctxt *ctxt)
 +{
 + u8 al = ctxt-dst.val  0xff;
 + u8 ah = (ctxt-dst.val  8)  0xff;
 +
 + al = (al + (ah * ctxt-src.val))  0xff;
 +
 + ctxt-dst.val = (ctxt-dst.val  0x) | al;
 +
 + ctxt-eflags = ~(X86_EFLAGS_PF | X86_EFLAGS_SF | X86_EFLAGS_ZF);
 +
 + if (!al)
 + ctxt-eflags |= X86_EFLAGS_ZF;
 + if (!(al  1))
 + ctxt-eflags |= X86_EFLAGS_PF;

This is wrong, it should check the parity of al (even=1, odd=0).

Perhaps you can use the trick of em_das:

/* Set PF, ZF, SF */
ctxt-src.type = OP_IMM;
ctxt-src.val = 0;
ctxt-src.bytes = 1;
emulate_2op_SrcV(ctxt, or);

Paolo

 + if (al  0x80)
 + ctxt-eflags |= X86_EFLAGS_SF;
 +
 + return X86EMUL_CONTINUE;
 +}
 +
  static int em_call(struct x86_emulate_ctxt *ctxt)
  {
   long rel = ctxt-src.val;
 @@ -3801,7 +3822,7 @@ static const struct opcode opcode_table[256] = {
   D(ImplicitOps | No64), II(ImplicitOps, em_iret, iret),
   /* 0xD0 - 0xD7 */
   D2bv(DstMem | SrcOne | ModRM), D2bv(DstMem | ModRM),
 - N, N, N, N,
 + N, I(DstAcc | SrcImmByte | No64, em_aad), N, N,
   /* 0xD8 - 0xDF */
   N, N, N, N, N, N, N, N,
   /* 0xE0 - 0xE7 */
 --
   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
 

--
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:linux-next 3/13] arch/x86/kvm/irq.c:46:18: warning: unused variable 's'

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
head:   0f888f5acd0cd806d4fd9f4067276b3855a13309
commit: f3200d00ea42e485772ff92d6d649aa8eeb640c0 [3/13] KVM: inject ExtINT 
interrupt before APIC interrupts
config: make ARCH=x86_64 allmodconfig

All warnings:

arch/x86/kvm/irq.c: In function 'kvm_cpu_has_interrupt':
arch/x86/kvm/irq.c:46:18: warning: unused variable 's' [-Wunused-variable]
arch/x86/kvm/irq.c: In function 'kvm_cpu_get_interrupt':
arch/x86/kvm/irq.c:63:18: warning: unused variable 's' [-Wunused-variable]

vim +/s +46 arch/x86/kvm/irq.c

85f455f7 drivers/kvm/irq.c  Eddie Dong  2007-07-06  30  /*
3d80840d arch/x86/kvm/irq.c Marcelo Tosatti 2008-04-11  31   * check if there 
are pending timer events
3d80840d arch/x86/kvm/irq.c Marcelo Tosatti 2008-04-11  32   * to be processed.
3d80840d arch/x86/kvm/irq.c Marcelo Tosatti 2008-04-11  33   */
3d80840d arch/x86/kvm/irq.c Marcelo Tosatti 2008-04-11  34  int 
kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
3d80840d arch/x86/kvm/irq.c Marcelo Tosatti 2008-04-11  35  {
23e7a794 arch/x86/kvm/irq.c Jason Wang  2010-08-27  36  return 
apic_has_pending_timer(vcpu);
3d80840d arch/x86/kvm/irq.c Marcelo Tosatti 2008-04-11  37  }
3d80840d arch/x86/kvm/irq.c Marcelo Tosatti 2008-04-11  38  
EXPORT_SYMBOL(kvm_cpu_has_pending_timer);
3d80840d arch/x86/kvm/irq.c Marcelo Tosatti 2008-04-11  39  
3d80840d arch/x86/kvm/irq.c Marcelo Tosatti 2008-04-11  40  /*
85f455f7 drivers/kvm/irq.c  Eddie Dong  2007-07-06  41   * check if there 
is pending interrupt without
85f455f7 drivers/kvm/irq.c  Eddie Dong  2007-07-06  42   * intack.
85f455f7 drivers/kvm/irq.c  Eddie Dong  2007-07-06  43   */
85f455f7 drivers/kvm/irq.c  Eddie Dong  2007-07-06  44  int 
kvm_cpu_has_interrupt(struct kvm_vcpu *v)
85f455f7 drivers/kvm/irq.c  Eddie Dong  2007-07-06  45  {
97222cc8 drivers/kvm/irq.c  Eddie Dong  2007-09-12 @46  struct kvm_pic 
*s;
97222cc8 drivers/kvm/irq.c  Eddie Dong  2007-09-12  47  
8061823a arch/x86/kvm/irq.c Gleb Natapov2009-04-21  48  if 
(!irqchip_in_kernel(v-kvm))
923c61bb arch/x86/kvm/irq.c Gleb Natapov2009-05-11  49  return 
v-arch.interrupt.pending;
8061823a arch/x86/kvm/irq.c Gleb Natapov2009-04-21  50  
f3200d00 arch/x86/kvm/irq.c Gleb Natapov2012-12-10  51  if 
(kvm_apic_accept_pic_intr(v)  pic_irqchip(v-kvm)-output)
f3200d00 arch/x86/kvm/irq.c Gleb Natapov2012-12-10  52  return 
pic_irqchip(v-kvm)-output; /* PIC */
f3200d00 arch/x86/kvm/irq.c Gleb Natapov2012-12-10  53  
f3200d00 arch/x86/kvm/irq.c Gleb Natapov2012-12-10  54  return 
kvm_apic_has_interrupt(v) != -1; /* LAPIC */

---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu  Intel Corporation
--
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: Don't use vcpu-requests for steal time accounting

[Gleb Natapov]

On Fri, Dec 14, 2012 at 07:37:18PM +0900, Takuya Yoshikawa wrote:
 We can check if accum_steal has any positive value instead of using
 KVM_REQ_STEAL_UPDATE bit in vcpu-requests; and this is the way we
 usually do for accounting for something in the kernel.
 
Now you added check that will be done on each guest entry, requests
mechanism prevents that.

 Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
 ---
  arch/x86/kvm/x86.c   |   11 +--
  include/linux/kvm_host.h |   41 -
  2 files changed, 25 insertions(+), 27 deletions(-)
 
 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
 index 57c76e8..fab4c3e 100644
 --- a/arch/x86/kvm/x86.c
 +++ b/arch/x86/kvm/x86.c
 @@ -1857,6 +1857,9 @@ static void accumulate_steal_time(struct kvm_vcpu *vcpu)
  
  static void record_steal_time(struct kvm_vcpu *vcpu)
  {
 + if (!vcpu-arch.st.accum_steal)
 + return;
 +
   if (!(vcpu-arch.st.msr_val  KVM_MSR_ENABLED))
   return;
  
 @@ -1992,9 +1995,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
 msr_data *msr_info)
   preempt_disable();
   accumulate_steal_time(vcpu);
   preempt_enable();
 -
 - kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
 -
   break;
   case MSR_KVM_PV_EOI_EN:
   if (kvm_lapic_enable_pv_eoi(vcpu, data))
 @@ -2668,7 +2668,6 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
   }
  
   accumulate_steal_time(vcpu);
 - kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
  }
  
  void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 @@ -5645,8 +5644,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
   r = 1;
   goto out;
   }
 - if (kvm_check_request(KVM_REQ_STEAL_UPDATE, vcpu))
 - record_steal_time(vcpu);
   if (kvm_check_request(KVM_REQ_NMI, vcpu))
   process_nmi(vcpu);
   req_immediate_exit =
 @@ -5672,6 +5669,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
   }
   }
  
 + record_steal_time(vcpu);
 +
   r = kvm_mmu_reload(vcpu);
   if (unlikely(r)) {
   goto cancel_injection;
 diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
 index 91ae127..5476ffc 100644
 --- a/include/linux/kvm_host.h
 +++ b/include/linux/kvm_host.h
 @@ -112,27 +112,26 @@ static inline bool is_error_page(struct page *page)
  /*
   * vcpu-requests bit members
   */
 -#define KVM_REQ_TLB_FLUSH  0
 -#define KVM_REQ_MIGRATE_TIMER  1
 -#define KVM_REQ_REPORT_TPR_ACCESS  2
 -#define KVM_REQ_MMU_RELOAD 3
 -#define KVM_REQ_TRIPLE_FAULT   4
 -#define KVM_REQ_PENDING_TIMER  5
 -#define KVM_REQ_UNHALT 6
 -#define KVM_REQ_MMU_SYNC   7
 -#define KVM_REQ_CLOCK_UPDATE   8
 -#define KVM_REQ_KICK   9
 -#define KVM_REQ_DEACTIVATE_FPU10
 -#define KVM_REQ_EVENT 11
 -#define KVM_REQ_APF_HALT  12
 -#define KVM_REQ_STEAL_UPDATE  13
 -#define KVM_REQ_NMI   14
 -#define KVM_REQ_IMMEDIATE_EXIT15
 -#define KVM_REQ_PMU   16
 -#define KVM_REQ_PMI   17
 -#define KVM_REQ_WATCHDOG  18
 -#define KVM_REQ_MASTERCLOCK_UPDATE 19
 -#define KVM_REQ_MCLOCK_INPROGRESS 20
 +#define KVM_REQ_TLB_FLUSH0
 +#define KVM_REQ_MIGRATE_TIMER1
 +#define KVM_REQ_REPORT_TPR_ACCESS2
 +#define KVM_REQ_MMU_RELOAD   3
 +#define KVM_REQ_TRIPLE_FAULT 4
 +#define KVM_REQ_PENDING_TIMER5
 +#define KVM_REQ_UNHALT   6
 +#define KVM_REQ_MMU_SYNC 7
 +#define KVM_REQ_CLOCK_UPDATE 8
 +#define KVM_REQ_KICK 9
 +#define KVM_REQ_DEACTIVATE_FPU   10
 +#define KVM_REQ_EVENT11
 +#define KVM_REQ_APF_HALT 12
 +#define KVM_REQ_NMI  13
 +#define KVM_REQ_IMMEDIATE_EXIT   14
 +#define KVM_REQ_PMU  15
 +#define KVM_REQ_PMI  16
 +#define KVM_REQ_WATCHDOG 17
 +#define KVM_REQ_MASTERCLOCK_UPDATE   18
 +#define KVM_REQ_MCLOCK_INPROGRESS19
  
  #define KVM_USERSPACE_IRQ_SOURCE_ID  0
  #define KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID 1
 -- 
 1.7.5.4

--
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: emulator: implement AAD instruction

[Gleb Natapov]

On Fri, Dec 14, 2012 at 11:44:22AM +0100, Paolo Bonzini wrote:
 Il 10/12/2012 10:42, Gleb Natapov ha scritto:
  Windows2000 uses it during boot. This fixes
  https://bugzilla.kernel.org/show_bug.cgi?id=50921
  
  Signed-off-by: Gleb Natapov g...@redhat.com
  diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
  index 39171cb..92c7292 100644
  --- a/arch/x86/kvm/emulate.c
  +++ b/arch/x86/kvm/emulate.c
  @@ -2852,6 +2852,27 @@ static int em_das(struct x86_emulate_ctxt *ctxt)
  return X86EMUL_CONTINUE;
   }
   
  +static int em_aad(struct x86_emulate_ctxt *ctxt)
  +{
  +   u8 al = ctxt-dst.val  0xff;
  +   u8 ah = (ctxt-dst.val  8)  0xff;
  +
  +   al = (al + (ah * ctxt-src.val))  0xff;
  +
  +   ctxt-dst.val = (ctxt-dst.val  0x) | al;
  +
  +   ctxt-eflags = ~(X86_EFLAGS_PF | X86_EFLAGS_SF | X86_EFLAGS_ZF);
  +
  +   if (!al)
  +   ctxt-eflags |= X86_EFLAGS_ZF;
  +   if (!(al  1))
  +   ctxt-eflags |= X86_EFLAGS_PF;
 
 This is wrong, it should check the parity of al (even=1, odd=0).
 
Oops, yes it should check number of bits set, not value itself.

 Perhaps you can use the trick of em_das:
 
 /* Set PF, ZF, SF */
 ctxt-src.type = OP_IMM;
 ctxt-src.val = 0;
 ctxt-src.bytes = 1;
 emulate_2op_SrcV(ctxt, or);
Will do.

 
 Paolo
 
  +   if (al  0x80)
  +   ctxt-eflags |= X86_EFLAGS_SF;
  +
  +   return X86EMUL_CONTINUE;
  +}
  +
   static int em_call(struct x86_emulate_ctxt *ctxt)
   {
  long rel = ctxt-src.val;
  @@ -3801,7 +3822,7 @@ static const struct opcode opcode_table[256] = {
  D(ImplicitOps | No64), II(ImplicitOps, em_iret, iret),
  /* 0xD0 - 0xD7 */
  D2bv(DstMem | SrcOne | ModRM), D2bv(DstMem | ModRM),
  -   N, N, N, N,
  +   N, I(DstAcc | SrcImmByte | No64, em_aad), N, N,
  /* 0xD8 - 0xDF */
  N, N, N, N, N, N, N, N,
  /* 0xE0 - 0xE7 */
  --
  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
  

--
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: emulator: implement AAD instruction

[Gleb Natapov]

On Fri, Dec 14, 2012 at 01:29:19PM +0200, Gleb Natapov wrote:
 On Fri, Dec 14, 2012 at 11:44:22AM +0100, Paolo Bonzini wrote:
  Il 10/12/2012 10:42, Gleb Natapov ha scritto:
   Windows2000 uses it during boot. This fixes
   https://bugzilla.kernel.org/show_bug.cgi?id=50921
   
   Signed-off-by: Gleb Natapov g...@redhat.com
   diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
   index 39171cb..92c7292 100644
   --- a/arch/x86/kvm/emulate.c
   +++ b/arch/x86/kvm/emulate.c
   @@ -2852,6 +2852,27 @@ static int em_das(struct x86_emulate_ctxt *ctxt)
 return X86EMUL_CONTINUE;
}

   +static int em_aad(struct x86_emulate_ctxt *ctxt)
   +{
   + u8 al = ctxt-dst.val  0xff;
   + u8 ah = (ctxt-dst.val  8)  0xff;
   +
   + al = (al + (ah * ctxt-src.val))  0xff;
   +
   + ctxt-dst.val = (ctxt-dst.val  0x) | al;
   +
   + ctxt-eflags = ~(X86_EFLAGS_PF | X86_EFLAGS_SF | X86_EFLAGS_ZF);
   +
   + if (!al)
   + ctxt-eflags |= X86_EFLAGS_ZF;
   + if (!(al  1))
   + ctxt-eflags |= X86_EFLAGS_PF;
  
  This is wrong, it should check the parity of al (even=1, odd=0).
  
 Oops, yes it should check number of bits set, not value itself.
 
  Perhaps you can use the trick of em_das:
  
  /* Set PF, ZF, SF */
  ctxt-src.type = OP_IMM;
  ctxt-src.val = 0;
  ctxt-src.bytes = 1;
  emulate_2op_SrcV(ctxt, or);
 Will do.
 
The patch is applied already. Paolo do you mind to send the fix?

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

KVM: remove unused variable. variable 's'

[Gleb Natapov]

Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index ebd98d0..b111aee 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -43,8 +43,6 @@ EXPORT_SYMBOL(kvm_cpu_has_pending_timer);
  */
 int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
 {
-   struct kvm_pic *s;
-
if (!irqchip_in_kernel(v-kvm))
return v-arch.interrupt.pending;
 
@@ -60,8 +58,6 @@ EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
  */
 int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
 {
-   struct kvm_pic *s;
-
if (!irqchip_in_kernel(v-kvm))
return v-arch.interrupt.nr;
 
--
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

[PATCH] KVM: remove unused variable.

[Gleb Natapov]

Signed-off-by: Gleb Natapov g...@redhat.com
---

Resend with fixed subject.

diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index ebd98d0..b111aee 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -43,8 +43,6 @@ EXPORT_SYMBOL(kvm_cpu_has_pending_timer);
  */
 int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
 {
-   struct kvm_pic *s;
-
if (!irqchip_in_kernel(v-kvm))
return v-arch.interrupt.pending;
 
@@ -60,8 +58,6 @@ EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
  */
 int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
 {
-   struct kvm_pic *s;
-
if (!irqchip_in_kernel(v-kvm))
return v-arch.interrupt.nr;
 
--
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: emulator: implement AAD instruction

[Paolo Bonzini]

Il 14/12/2012 13:42, Gleb Natapov ha scritto:
 On Fri, Dec 14, 2012 at 01:29:19PM +0200, Gleb Natapov wrote:
 On Fri, Dec 14, 2012 at 11:44:22AM +0100, Paolo Bonzini wrote:
 Il 10/12/2012 10:42, Gleb Natapov ha scritto:
 Windows2000 uses it during boot. This fixes
 https://bugzilla.kernel.org/show_bug.cgi?id=50921

 Signed-off-by: Gleb Natapov g...@redhat.com
 diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
 index 39171cb..92c7292 100644
 --- a/arch/x86/kvm/emulate.c
 +++ b/arch/x86/kvm/emulate.c
 @@ -2852,6 +2852,27 @@ static int em_das(struct x86_emulate_ctxt *ctxt)
return X86EMUL_CONTINUE;
  }
  
 +static int em_aad(struct x86_emulate_ctxt *ctxt)
 +{
 +  u8 al = ctxt-dst.val  0xff;
 +  u8 ah = (ctxt-dst.val  8)  0xff;
 +
 +  al = (al + (ah * ctxt-src.val))  0xff;
 +
 +  ctxt-dst.val = (ctxt-dst.val  0x) | al;
 +
 +  ctxt-eflags = ~(X86_EFLAGS_PF | X86_EFLAGS_SF | X86_EFLAGS_ZF);
 +
 +  if (!al)
 +  ctxt-eflags |= X86_EFLAGS_ZF;
 +  if (!(al  1))
 +  ctxt-eflags |= X86_EFLAGS_PF;

 This is wrong, it should check the parity of al (even=1, odd=0).

 Oops, yes it should check number of bits set, not value itself.

 Perhaps you can use the trick of em_das:

 /* Set PF, ZF, SF */
 ctxt-src.type = OP_IMM;
 ctxt-src.val = 0;
 ctxt-src.bytes = 1;
 emulate_2op_SrcV(ctxt, or);
 Will do.

 The patch is applied already. Paolo do you mind to send the fix?

Ok, I'll also add a testcase.

Paolo

--
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: inject ExtINT interrupt before APIC interrupts

[Marcelo Tosatti]

On Wed, Dec 12, 2012 at 12:39:02AM +, Zhang, Yang Z wrote:
 Gleb Natapov wrote on 2012-12-10:
  According to Intel SDM Volume 3 Section 10.8.1 Interrupt Handling with
  the Pentium 4 and Intel Xeon Processors and Section 10.8.2 Interrupt
  Handling with the P6 Family and Pentium Processors ExtINT interrupts are
  sent directly to the processor core for handling. Currently KVM checks
  APIC before it considers ExtINT interrupts for injection which is
  backwards from the spec. Make code behave according to the SDM.
 Ack.

Applied, thanks.

--
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 unit-test] test aad instruction

[Marcelo Tosatti]

On Mon, Dec 10, 2012 at 11:44:35AM +0200, Gleb Natapov wrote:
 Add test for aad instruction emulation.
 
 Signed-off-by: Gleb Natapov g...@redhat.com

Applied, thanks.

--
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 RFC 1/2] sched: Bail out of yield_to when source and target runqueue has one task

[Marcelo Tosatti]

Raghavendra,

Please get this integrate through x86 tree (Ingo CC'ed).

On Mon, Nov 26, 2012 at 05:37:54PM +0530, Raghavendra K T wrote:
 From: Peter Zijlstra pet...@infradead.org
 
 In case of undercomitted scenarios, especially in large guests
 yield_to overhead is significantly high. when run queue length of
 source and target is one, take an opportunity to bail out and return
 -ESRCH. This return condition can be further exploited to quickly come
 out of PLE handler.
 
 (History: Raghavendra initially worked on break out of kvm ple handler upon
  seeing source runqueue length = 1, but it had to export rq length).
  Peter came up with the elegant idea of return -ESRCH in scheduler core.
 
 Signed-off-by: Peter Zijlstra pet...@infradead.org
 Raghavendra, Checking the rq length of target vcpu condition added.(thanks 
 Avi)
 Reviewed-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
 Signed-off-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com
 ---
 
  kernel/sched/core.c |   25 +++--
  1 file changed, 19 insertions(+), 6 deletions(-)
 
 diff --git a/kernel/sched/core.c b/kernel/sched/core.c
 index 2d8927f..fc219a5 100644
 --- a/kernel/sched/core.c
 +++ b/kernel/sched/core.c
 @@ -4289,7 +4289,10 @@ EXPORT_SYMBOL(yield);
   * It's the caller's job to ensure that the target task struct
   * can't go away on us before we can do any checks.
   *
 - * Returns true if we indeed boosted the target task.
 + * Returns:
 + *   true (0) if we indeed boosted the target task.
 + *   false (0) if we failed to boost the target.
 + *   -ESRCH if there's no task to yield to.
   */
  bool __sched yield_to(struct task_struct *p, bool preempt)
  {
 @@ -4303,6 +4306,15 @@ bool __sched yield_to(struct task_struct *p, bool 
 preempt)
  
  again:
   p_rq = task_rq(p);
 + /*
 +  * If we're the only runnable task on the rq and target rq also
 +  * has only one task, there's absolutely no point in yielding.
 +  */
 + if (rq-nr_running == 1  p_rq-nr_running == 1) {
 + yielded = -ESRCH;
 + goto out_irq;
 + }
 +
   double_rq_lock(rq, p_rq);
   while (task_rq(p) != p_rq) {
   double_rq_unlock(rq, p_rq);
 @@ -4310,13 +4322,13 @@ again:
   }
  
   if (!curr-sched_class-yield_to_task)
 - goto out;
 + goto out_unlock;
  
   if (curr-sched_class != p-sched_class)
 - goto out;
 + goto out_unlock;
  
   if (task_running(p_rq, p) || p-state)
 - goto out;
 + goto out_unlock;
  
   yielded = curr-sched_class-yield_to_task(rq, p, preempt);
   if (yielded) {
 @@ -4329,11 +4341,12 @@ again:
   resched_task(p_rq-curr);
   }
  
 -out:
 +out_unlock:
   double_rq_unlock(rq, p_rq);
 +out_irq:
   local_irq_restore(flags);
  
 - if (yielded)
 + if (yielded  0)
   schedule();
  
   return yielded;
 
 --
 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
--
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: Don't use vcpu-requests for steal time accounting

[Takuya Yoshikawa]

On Fri, 14 Dec 2012 13:28:15 +0200
Gleb Natapov g...@redhat.com wrote:

 On Fri, Dec 14, 2012 at 07:37:18PM +0900, Takuya Yoshikawa wrote:
  We can check if accum_steal has any positive value instead of using
  KVM_REQ_STEAL_UPDATE bit in vcpu-requests; and this is the way we
  usually do for accounting for something in the kernel.
  
 Now you added check that will be done on each guest entry, requests
 mechanism prevents that.

Yes, +1 if for the case we have nothing in requests.

I'm not sure if setting and clearing a bit for that minor
optimization is worth it.

Thanks,
Takuya
--
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: Don't use vcpu-requests for steal time accounting

[Gleb Natapov]

On Sat, Dec 15, 2012 at 12:12:08AM +0900, Takuya Yoshikawa wrote:
 On Fri, 14 Dec 2012 13:28:15 +0200
 Gleb Natapov g...@redhat.com wrote:
 
  On Fri, Dec 14, 2012 at 07:37:18PM +0900, Takuya Yoshikawa wrote:
   We can check if accum_steal has any positive value instead of using
   KVM_REQ_STEAL_UPDATE bit in vcpu-requests; and this is the way we
   usually do for accounting for something in the kernel.
   
  Now you added check that will be done on each guest entry, requests
  mechanism prevents that.
 
 Yes, +1 if for the case we have nothing in requests.
 
Almost any bit in requests can be replaced by one if. Those
if's add up.

 I'm not sure if setting and clearing a bit for that minor
 optimization is worth it.
 
Setting/clearing it should be much more rare than guest entry.

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

[PATCH 2/3] s390/ccwdev: Include asm/schid.h.

[Cornelia Huck]

Get the definition of struct subchannel_id.

Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
 arch/s390/include/asm/ccwdev.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/s390/include/asm/ccwdev.h b/arch/s390/include/asm/ccwdev.h
index 6d1f357..e606161 100644
--- a/arch/s390/include/asm/ccwdev.h
+++ b/arch/s390/include/asm/ccwdev.h
@@ -12,15 +12,13 @@
 #include linux/mod_devicetable.h
 #include asm/fcx.h
 #include asm/irq.h
+#include asm/schid.h
 
 /* structs from asm/cio.h */
 struct irb;
 struct ccw1;
 struct ccw_dev_id;
 
-/* from asm/schid.h */
-struct subchannel_id;
-
 /* simplified initializers for struct ccw_device:
  * CCW_DEVICE and CCW_DEVICE_DEVTYPE initialize one
  * entry in your MODULE_DEVICE_TABLE and set the match_flag correctly */
-- 
1.7.12.4

--
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 v5 0/3] s390: Guest support for virtio-ccw.

[Cornelia Huck]

Hi,

here's the virtio-ccw guest support for kvm/next again.

The not-kvm specific patches have made their way upstream via the
s390 tree in the meantime. Patch 2 fixes an inconsistency there.

Patch 3 lost the now unneeded schid.h include; otherwise, the patches
are unchanged from v4.

Cornelia Huck (3):
  KVM: s390: Handle hosts not supporting s390-virtio.
  s390/ccwdev: Include asm/schid.h.
  KVM: s390: Add a channel I/O based virtio transport driver.

 arch/s390/include/asm/ccwdev.h |   4 +-
 arch/s390/include/asm/irq.h|   1 +
 arch/s390/kernel/irq.c |   1 +
 drivers/s390/kvm/Makefile  |   2 +-
 drivers/s390/kvm/kvm_virtio.c  |  38 +-
 drivers/s390/kvm/virtio_ccw.c  | 853 +
 6 files changed, 887 insertions(+), 12 deletions(-)
 create mode 100644 drivers/s390/kvm/virtio_ccw.c

-- 
1.7.12.4

--
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 3/3] KVM: s390: Add a channel I/O based virtio transport driver.

[Cornelia Huck]

Add a driver for kvm guests that matches virtual ccw devices provided
by the host as virtio bridge devices.

These virtio-ccw devices use a special set of channel commands in order
to perform virtio functions.

Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
 arch/s390/include/asm/irq.h   |   1 +
 arch/s390/kernel/irq.c|   1 +
 drivers/s390/kvm/Makefile |   2 +-
 drivers/s390/kvm/virtio_ccw.c | 853 ++
 4 files changed, 856 insertions(+), 1 deletion(-)
 create mode 100644 drivers/s390/kvm/virtio_ccw.c

diff --git a/arch/s390/include/asm/irq.h b/arch/s390/include/asm/irq.h
index e6972f8..aa6d0d7 100644
--- a/arch/s390/include/asm/irq.h
+++ b/arch/s390/include/asm/irq.h
@@ -35,6 +35,7 @@ enum interruption_class {
IOINT_CSC,
IOINT_PCI,
IOINT_MSI,
+   IOINT_VIR,
NMI_NMI,
NR_IRQS,
 };
diff --git a/arch/s390/kernel/irq.c b/arch/s390/kernel/irq.c
index bf24293..a9806ea 100644
--- a/arch/s390/kernel/irq.c
+++ b/arch/s390/kernel/irq.c
@@ -60,6 +60,7 @@ static const struct irq_class intrclass_names[] = {
[IOINT_CSC]  = {.name = CSC, .desc = [I/O] CHSC Subchannel},
[IOINT_PCI]  = {.name = PCI, .desc = [I/O] PCI Interrupt },
[IOINT_MSI] =  {.name = MSI, .desc = [I/O] MSI Interrupt },
+   [IOINT_VIR]  = {.name = VIR, .desc = [I/O] Virtual I/O Devices},
[NMI_NMI]= {.name = NMI, .desc = [NMI] Machine Check},
 };
 
diff --git a/drivers/s390/kvm/Makefile b/drivers/s390/kvm/Makefile
index 0815690..241891a 100644
--- a/drivers/s390/kvm/Makefile
+++ b/drivers/s390/kvm/Makefile
@@ -6,4 +6,4 @@
 # it under the terms of the GNU General Public License (version 2 only)
 # as published by the Free Software Foundation.
 
-obj-$(CONFIG_S390_GUEST) += kvm_virtio.o
+obj-$(CONFIG_S390_GUEST) += kvm_virtio.o virtio_ccw.o
diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c
new file mode 100644
index 000..1a5aff3
--- /dev/null
+++ b/drivers/s390/kvm/virtio_ccw.c
@@ -0,0 +1,853 @@
+/*
+ * ccw based virtio transport
+ *
+ * Copyright IBM Corp. 2012
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (version 2 only)
+ * as published by the Free Software Foundation.
+ *
+ *Author(s): Cornelia Huck cornelia.h...@de.ibm.com
+ */
+
+#include linux/kernel_stat.h
+#include linux/init.h
+#include linux/bootmem.h
+#include linux/err.h
+#include linux/virtio.h
+#include linux/virtio_config.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/virtio_ring.h
+#include linux/pfn.h
+#include linux/async.h
+#include linux/wait.h
+#include linux/list.h
+#include linux/bitops.h
+#include linux/module.h
+#include linux/io.h
+#include linux/kvm_para.h
+#include asm/setup.h
+#include asm/irq.h
+#include asm/cio.h
+#include asm/ccwdev.h
+
+/*
+ * virtio related functions
+ */
+
+struct vq_config_block {
+   __u16 index;
+   __u16 num;
+} __packed;
+
+#define VIRTIO_CCW_CONFIG_SIZE 0x100
+/* same as PCI config space size, should be enough for all drivers */
+
+struct virtio_ccw_device {
+   struct virtio_device vdev;
+   __u8 status;
+   __u8 config[VIRTIO_CCW_CONFIG_SIZE];
+   struct ccw_device *cdev;
+   struct ccw1 *ccw;
+   __u32 area;
+   __u32 curr_io;
+   int err;
+   wait_queue_head_t wait_q;
+   spinlock_t lock;
+   struct list_head virtqueues;
+   unsigned long indicators;
+   unsigned long indicators2;
+   struct vq_config_block *config_block;
+};
+
+struct vq_info_block {
+   __u64 queue;
+   __u32 align;
+   __u16 index;
+   __u16 num;
+} __packed;
+
+struct virtio_feature_desc {
+   __u32 features;
+   __u8 index;
+} __packed;
+
+struct virtio_ccw_vq_info {
+   struct virtqueue *vq;
+   int num;
+   void *queue;
+   struct vq_info_block *info_block;
+   struct list_head node;
+};
+
+#define KVM_VIRTIO_CCW_RING_ALIGN 4096
+
+#define KVM_S390_VIRTIO_CCW_NOTIFY 3
+
+#define CCW_CMD_SET_VQ 0x13
+#define CCW_CMD_VDEV_RESET 0x33
+#define CCW_CMD_SET_IND 0x43
+#define CCW_CMD_SET_CONF_IND 0x53
+#define CCW_CMD_READ_FEAT 0x12
+#define CCW_CMD_WRITE_FEAT 0x11
+#define CCW_CMD_READ_CONF 0x22
+#define CCW_CMD_WRITE_CONF 0x21
+#define CCW_CMD_WRITE_STATUS 0x31
+#define CCW_CMD_READ_VQ_CONF 0x32
+
+#define VIRTIO_CCW_DOING_SET_VQ 0x0001
+#define VIRTIO_CCW_DOING_RESET 0x0004
+#define VIRTIO_CCW_DOING_READ_FEAT 0x0008
+#define VIRTIO_CCW_DOING_WRITE_FEAT 0x0010
+#define VIRTIO_CCW_DOING_READ_CONFIG 0x0020
+#define VIRTIO_CCW_DOING_WRITE_CONFIG 0x0040
+#define VIRTIO_CCW_DOING_WRITE_STATUS 0x0080
+#define VIRTIO_CCW_DOING_SET_IND 0x0100
+#define VIRTIO_CCW_DOING_READ_VQ_CONF 0x0200
+#define VIRTIO_CCW_DOING_SET_CONF_IND 0x0400
+#define VIRTIO_CCW_INTPARM_MASK 0x
+
+static struct 

[PATCH 1/3] KVM: s390: Handle hosts not supporting s390-virtio.

[Cornelia Huck]

Running under a kvm host does not necessarily imply the presence of
a page mapped above the main memory with the virtio information;
however, the code includes a hard coded access to that page.

Instead, check for the presence of the page and exit gracefully
before we hit an addressing exception if it does not exist.

Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
cc: sta...@vger.kernel.org
---
 drivers/s390/kvm/kvm_virtio.c | 38 ++
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/drivers/s390/kvm/kvm_virtio.c b/drivers/s390/kvm/kvm_virtio.c
index 7dabef6..b846b6c 100644
--- a/drivers/s390/kvm/kvm_virtio.c
+++ b/drivers/s390/kvm/kvm_virtio.c
@@ -422,6 +422,26 @@ static void kvm_extint_handler(struct ext_code ext_code,
 }
 
 /*
+ * For s390-virtio, we expect a page above main storage containing
+ * the virtio configuration. Try to actually load from this area
+ * in order to figure out if the host provides this page.
+ */
+static int __init test_devices_support(unsigned long addr)
+{
+   int ret = -EIO;
+
+   asm volatile(
+   0: lura0,%1\n
+   1: xgr %0,%0\n
+   2:\n
+   EX_TABLE(0b,2b)
+   EX_TABLE(1b,2b)
+   : +d (ret)
+   : a (addr)
+   : 0, cc);
+   return ret;
+}
+/*
  * Init function for virtio
  * devices are in a single page above top of normal mem
  */
@@ -432,21 +452,23 @@ static int __init kvm_devices_init(void)
if (!MACHINE_IS_KVM)
return -ENODEV;
 
+   if (test_devices_support(real_memory_size)  0)
+   return -ENODEV;
+
+   rc = vmem_add_mapping(real_memory_size, PAGE_SIZE);
+   if (rc)
+   return rc;
+
+   kvm_devices = (void *) real_memory_size;
+
kvm_root = root_device_register(kvm_s390);
if (IS_ERR(kvm_root)) {
rc = PTR_ERR(kvm_root);
printk(KERN_ERR Could not register kvm_s390 root device);
+   vmem_remove_mapping(real_memory_size, PAGE_SIZE);
return rc;
}
 
-   rc = vmem_add_mapping(real_memory_size, PAGE_SIZE);
-   if (rc) {
-   root_device_unregister(kvm_root);
-   return rc;
-   }
-
-   kvm_devices = (void *) real_memory_size;
-
INIT_WORK(hotplug_work, hotplug_devices);
 
service_subclass_irq_register();
-- 
1.7.12.4

--
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: DMAR and DRHD errors[DMAR:[fault reason 06] PTE Read access is not set] Vt-d intel_iommu

[Don Dutile]

On 12/13/2012 04:50 AM, Jason Gao wrote:

Dear List:

Description of problem:
After installed Centos 6.3(RHEL6.3) on my Dell R710(lastest
bios:Version: 6.3.0,Release Date: 07/24/2012) server,and updated
lastest kernel 2.6.32-279.14.1.el6.x86_64,I want to use the Intel
82576 ET Dual Port nic's SR-IOV feature,assigning VFs to kvm guest

appended kernel boot parameter: intel_iommu=on,after boot with the
following messages:

Dec 13 16:58:15 2 kernel: DRHD: handling fault status reg 2
Dec 13 16:58:15 2 kernel: DMAR:[DMA Read] Request device [03:00.0]
fault addr ffe65000
Dec 13 16:58:15 2 kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 13 16:58:15 2 kernel: DRHD: handling fault status reg 102
Dec 13 16:58:15 2 kernel: DMAR:[DMA Read] Request device [03:00.0]
fault addr ffe8a000
Dec 13 16:58:15 2 kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 13 16:58:15 2 kernel: scsi 0:0:32:0: Enclosure DP
BACKPLANE1.07 PQ: 0 ANSI: 5
Dec 13 16:58:15 2 kernel: DRHD: handling fault status reg 202
Dec 13 16:58:15 2 kernel: DMAR:[DMA Read] Request device [03:00.0]
fault addr ffe89000
Dec 13 16:58:15 2 kernel: DMAR:[fault reason 06] PTE Read access is not set

full dmesg detail:
http://pastebin.com/BzFQV0jU
lspci -vvv full detail:
http://pastebin.com/9rP2d1br


it's a production server,and I'm not sure if this is a critical
problem,how to fix it,any help would be greatly appreciated.


DMAR table does not have an entry for this device to this region.
Once the driver reconfigs/resets the device to stop polling bios-boot
cmd rings and use (new) OS (dma-mapped) rings, there's a period of time
during this transition that the hw is babbling away to an area that is no
longer mapped.

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


--
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: DMAR and DRHD errors[DMAR:[fault reason 06] PTE Read access is not set] Vt-d intel_iommu

[Don Dutile]

On 12/13/2012 09:01 PM, Jason Gao wrote:

On Fri, Dec 14, 2012 at 12:23 AM, Alex Williamson
alex.william...@redhat.com  wrote:


Device 03:00.0 is your raid controller:

03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 
04)

For some reason it's trying to read from ffe65000, ffe8a000, ffe89000,
ffe86000, ffe87000, ffe84000.  Those are in reserved memory regions, so
it's not reading an OS allocated buffer, which probably means it's some
kind of side-band communication with a management controller.  I'd guess
it's a BIOS bug and there should be an RMRR covering those accesses.
Thanks,


First of all ,I want to known whether I can ignore these errors on the
production server,and do these error may affect the system?

By the way,when I removed the intel_iommu=on from /etc/grub.conf,no
DMAR related errors occur


well, if you don't enable the IOMMU, then it won't have IOMMU faults! ;-)


It's a strange thing,other three Dell R710 servers with the same bios
version v. 6.3.0, same kernel 2.6.32-279.14.1 on RHEL6u3(Centos 6u3)
,but these errors don't appear on these tree servers


mptsas or smi fw has to be different


Anyone have any idea for this ?

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


--
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: DMAR and DRHD errors[DMAR:[fault reason 06] PTE Read access is not set] Vt-d intel_iommu

[Don Dutile]

On 12/13/2012 09:01 PM, Jason Gao wrote:

On Fri, Dec 14, 2012 at 12:23 AM, Alex Williamson
alex.william...@redhat.com  wrote:


Device 03:00.0 is your raid controller:

03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 
04)

For some reason it's trying to read from ffe65000, ffe8a000, ffe89000,
ffe86000, ffe87000, ffe84000.  Those are in reserved memory regions, so
it's not reading an OS allocated buffer, which probably means it's some
kind of side-band communication with a management controller.  I'd guess
it's a BIOS bug and there should be an RMRR covering those accesses.
Thanks,


First of all ,I want to known whether I can ignore these errors on the
production server,and do these error may affect the system?

By the way,when I removed the intel_iommu=on from /etc/grub.conf,no
DMAR related errors occur

It's a strange thing,other three Dell R710 servers with the same bios
version v. 6.3.0, same kernel 2.6.32-279.14.1 on RHEL6u3(Centos 6u3)
,but these errors don't appear on these tree servers


forgot: did you check that all the bios settings are the same btwn
the 710 systems?


Anyone have any idea for this ?

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


--
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: PPC: Book3S: PR: Enable alternative instruction for SC 1

[Alexander Graf]

When running on top of pHyp, the hypercall instruction sc 1 goes
straight into pHyp without trapping in supervisor mode.

So if we want to support PAPR guest in this configuration we need to
add a second way of accessing PAPR hypercalls, preferably with the
exact same semantics except for the instruction.

So let's overlay an officially reserved instruction and emulate PAPR
hypercalls whenever we hit that one.

Signed-off-by: Alexander Graf ag...@suse.de
---
 arch/powerpc/include/asm/kvm_ppc.h |1 +
 arch/powerpc/kvm/book3s_emulate.c  |   28 
 arch/powerpc/kvm/book3s_pr.c   |5 +
 3 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index 572aa75..5f5f69a 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -44,6 +44,7 @@ enum emulation_result {
EMULATE_DO_DCR,   /* kvm_run filled with DCR request */
EMULATE_FAIL, /* can't emulate this instruction */
EMULATE_AGAIN,/* something went wrong. go again */
+   EMULATE_DO_PAPR,  /* kvm_run filled with PAPR request */
 };
 
 extern int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu);
diff --git a/arch/powerpc/kvm/book3s_emulate.c 
b/arch/powerpc/kvm/book3s_emulate.c
index d31a716..c88161b 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -34,6 +34,8 @@
 #define OP_31_XOP_MTSRIN   242
 #define OP_31_XOP_TLBIEL   274
 #define OP_31_XOP_TLBIE306
+/* Opcode is officially reserved, reuse it as sc 1 when sc 1 doesn't trap */
+#define OP_31_XOP_FAKE_SC1 308
 #define OP_31_XOP_SLBMTE   402
 #define OP_31_XOP_SLBIE434
 #define OP_31_XOP_SLBIA498
@@ -170,6 +172,32 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct 
kvm_vcpu *vcpu,
vcpu-arch.mmu.tlbie(vcpu, addr, large);
break;
}
+#ifdef CONFIG_KVM_BOOK3S_64_PR
+   case OP_31_XOP_FAKE_SC1:
+   {
+   /* SC 1 papr hypercalls */
+   ulong cmd = kvmppc_get_gpr(vcpu, 3);
+   int i;
+
+   if ((vcpu-arch.shared-msr  MSR_PR) ||
+   !vcpu-arch.papr_enabled) {
+   emulated = EMULATE_FAIL;
+   break;
+   }
+
+   if (kvmppc_h_pr(vcpu, cmd) == EMULATE_DONE)
+   break;
+
+   run-papr_hcall.nr = cmd;
+   for (i = 0; i  9; ++i) {
+   ulong gpr = kvmppc_get_gpr(vcpu, 4 + i);
+   run-papr_hcall.args[i] = gpr;
+   }
+
+   emulated = EMULATE_DO_PAPR;
+   break;
+   }
+#endif
case OP_31_XOP_EIOIO:
break;
case OP_31_XOP_SLBMTE:
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 28d38ad..73ed11c 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -760,6 +760,11 @@ program_interrupt:
run-exit_reason = KVM_EXIT_MMIO;
r = RESUME_HOST_NV;
break;
+   case EMULATE_DO_PAPR:
+   run-exit_reason = KVM_EXIT_PAPR_HCALL;
+   vcpu-arch.hcall_needed = 1;
+   r = RESUME_HOST_NV;
+   break;
default:
BUG();
}
-- 
1.6.0.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

[PATCH] KVM: PPC: Only WARN on invalid emulation

[Alexander Graf]

When we hit an emulation result that we didn't expect, that is an error,
but it's nothing that warrants a BUG(), because it can be guest triggered.

So instead, let's only WARN() the user that this happened.

Signed-off-by: Alexander Graf ag...@suse.de

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index be83fca..e2225e5 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -237,7 +237,8 @@ int kvmppc_emulate_mmio(struct kvm_run *run, struct 
kvm_vcpu *vcpu)
r = RESUME_HOST;
break;
default:
-   BUG();
+   WARN_ON(1);
+   r = RESUME_GUEST;
}
 
return r;
--
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

vmx real mode emulated mmio?

[Alex Williamson]

I don't really know what I'm doing messing around with realmode
exception handling, but are we missing something like this:

--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4332,7 +4332,8 @@ static int handle_exception(struct kvm_vcpu *vcpu)
if (vcpu-arch.halt_request) {
vcpu-arch.halt_request = 0;
return kvm_emulate_halt(vcpu);
-   }
+   } else if (vcpu-mmio_needed)
+   return 0;
return 1;
}
 

The background is that I was playing around with when the MMIO regions
of PCI assigned devices get direct mapped through KVM and start using
memory slots and I found that the boot ROM on an e1000e card that I
often use for testing causes the VM to hang when not directly mapped
through a memory slot.  This happens with both pci-assign and vfio-pci.
Debugging further, I see the kernel instruction emulator decodes this
and sets all the necessary flags and fragments for userspace to complete
the access, but since it happened in real mode, vcpu_enter_guest always
returns 1 and therefore KVM_RUN never exits to userspace and KVM gets
stuck in an infinite loop re-handling this instruction.

The above is pretty trivial and allows the ROM to work again.  Is it
correct?  What other exceptions are we missing here that should allow an
exit?  This particular access generated a GP_VECTOR exception if we want
to key on that somewhere.  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: [RFC PATCH 0/9] KVM: PPC: In-kernel PAPR interrupt controller emulation

[Alexander Graf]

On 05.11.2012, at 04:18, Paul Mackerras wrote:

 This series implements in-kernel emulation of the XICS interrupt
 controller specified in the PAPR specification and used by pseries
 guests.  Since the XICS is organized a bit differently to the
 interrupt controllers used on x86 machines, I have defined some new
 ioctls for setting up the XICS and for saving and restoring its
 state.  It may be possible to use some of the currently x86-specific
 ioctls instead.

Is this one already following the new world order that we discussed during KVM 
Forum? :)


Alex

 
 Paul.
 --
 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

--
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 v2 00/10] kvm: memory slot cleanups, fix, and increase

[Marcelo Tosatti]

On Mon, Dec 10, 2012 at 10:32:39AM -0700, Alex Williamson wrote:
 v2: Update 02/10 to not check userspace_addr when slot is removed.
 Yoshikawa-san withdrew objection to increase slot_bitmap prior
 to his series to remove slot_bitmap.
 
 This series does away with any kind of complicated resizing of the
 slot array and simply does a one time increase.  I do compact struct
 kvm_memory_slot a bit to take better advantage of the space we are
 using.  This reduces each slot from 64 bytes (x86_64) to 56 bytes.
 By enforcing the API around valid operations for an unused slot and
 fields that can be modified runtime, I found and was able to fix a
 bug in iommu mapping for slots.  The renames enabled me to find the
 previously posted bug fix for catching slot overlaps.
 
 As mentioned in the series, the primary motivation for increasing
 memory slots is assigned devices.  With this, I've been able to
 assign 30 devices to a single VM and could have gone further, but
 ran out of SRIOV VFs.  Typical devices use anywhere from 2-4 slots
 and max out at 8 slots.  125 user slots (3 private slots) allows
 us to support between 28 and 56 typical devices per VM.
 
 Tested on x86_64, compiled on ia64, powerpc, and s390.
 
 Thanks,
 Alex

Applied, thanks.

--
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 v2 0/5] KVM: x86: improve reexecute_instruction

[Marcelo Tosatti]

On Fri, Dec 14, 2012 at 12:50:09PM +0800, Xiao Guangrong wrote:
  program a timer interrupt and #GP? 
 
  Could you please explain the detail?
  
  Before the instruction which writes continuously to the pagetable, arm
  say lapic timer. #GP on the interrupt handler and test with failure.
 
 Sorry, I am confused about this. After Qemu exits due to 
 KVM_EXIT_INTERNAL_ERROR,
 the vm is stopped then interrupt can not be injected to guest. Or i missed 
 something?

Yes, but without fixed kernel kvm-unit test executable loops continuously.
Perhaps its more appropriate to fix generically, nevermind.

--
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: percpu allocation failures in kvm

[Marcelo Tosatti]

On Thu, Dec 13, 2012 at 09:43:23PM -0800, Andy Lutomirski wrote:
 On 3.7.0 + irrelevant patches, I get this on boot.  I've seen it on
 and off on earlier kernels, I think (although I'm not currently
 getting it on 3.5).
 
 [   10.230054] PERCPU: allocation failed, size=304 align=32, alloc
 from reserved chunk failed
 [   10.230059] Pid: 1026, comm: modprobe Tainted: GW3.7.0-ama+ #5
 [   10.230060] Call Trace:
 [   10.230070]  [81129efb] pcpu_alloc+0x9db/0xa40
 [   10.230074]  [810a81ad] ? find_symbol_in_section+0x4d/0x140
 [   10.230077]  [810a8160] ? finished_loading+0x50/0x50
 [   10.230080]  [810a8af0] ? each_symbol_section+0x30/0x70
 [   10.230083]  [810a8b61] ? find_symbol+0x31/0x60
 [   10.230086]  [8112a1f3] __alloc_reserved_percpu+0x13/0x20
 [   10.230089]  [810ab48d] load_module+0x3ed/0x1b50
 [   10.230093]  [81075c3b] ? __srcu_read_unlock+0x4b/0x70
 
 --Andy

You're loading the kvm module, or loading some other module inside
a kvm guest?

--
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: percpu allocation failures in kvm

[Andy Lutomirski]

On Fri, Dec 14, 2012 at 5:03 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
 On Thu, Dec 13, 2012 at 09:43:23PM -0800, Andy Lutomirski wrote:
 On 3.7.0 + irrelevant patches, I get this on boot.  I've seen it on
 and off on earlier kernels, I think (although I'm not currently
 getting it on 3.5).

 [   10.230054] PERCPU: allocation failed, size=304 align=32, alloc
 from reserved chunk failed
 [   10.230059] Pid: 1026, comm: modprobe Tainted: GW3.7.0-ama+ #5
 [   10.230060] Call Trace:
 [   10.230070]  [81129efb] pcpu_alloc+0x9db/0xa40
 [   10.230074]  [810a81ad] ? find_symbol_in_section+0x4d/0x140
 [   10.230077]  [810a8160] ? finished_loading+0x50/0x50
 [   10.230080]  [810a8af0] ? each_symbol_section+0x30/0x70
 [   10.230083]  [810a8b61] ? find_symbol+0x31/0x60
 [   10.230086]  [8112a1f3] __alloc_reserved_percpu+0x13/0x20
 [   10.230089]  [810ab48d] load_module+0x3ed/0x1b50
 [   10.230093]  [81075c3b] ? __srcu_read_unlock+0x4b/0x70

 --Andy

 You're loading the kvm module, or loading some other module inside
 a kvm guest?


This is loading the kvm module on startup.  There are no guests.

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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: [RFC PATCH 0/9] KVM: PPC: In-kernel PAPR interrupt controller emulation

[Benjamin Herrenschmidt]

On Sat, 2012-12-15 at 01:46 +0100, Alexander Graf wrote:
 On 05.11.2012, at 04:18, Paul Mackerras wrote:
 
  This series implements in-kernel emulation of the XICS interrupt
  controller specified in the PAPR specification and used by pseries
  guests.  Since the XICS is organized a bit differently to the
  interrupt controllers used on x86 machines, I have defined some new
  ioctls for setting up the XICS and for saving and restoring its
  state.  It may be possible to use some of the currently x86-specific
  ioctls instead.
 
 Is this one already following the new world order that we discussed during 
 KVM Forum? :)

The new world order  (sorry, looks like nobody took notes and
people expect me to do a write up from memory now ... :-)

Well, mostly we agreed that the x86 stuff wasn't going to work for us.

So basically what we discussed boils down to:

 - Move the existing generic KVM ioctl to create the kernel APIC to
x86 since it's no as-is useful for other archs who, among other things,
might need to pass argument based on the machine type (type of interrupt
subsystem for example, etc...)

 - Once that's done, well, instanciating interrupt controller objects
becomes pretty much an arch specific matter. We could try to keep some
ioctls somewhat common though it's not *that* useful because the various
types  arguments are going to be fairly arch specific, so goes for
configuration. Examples of what could be kept common are:

   * Create irq chip, takes at least a type argument, possibly a few
more type-specific args (or a union, but then let's keep space in there
since we can't change the size of the struct later as it would impact
the ioctl number afaik).

  * Assigning the address of an irq chip when it can change (see ARM
patches)

 - The existing business with irqfd etc... is mostly ok, except the
interfaces messing around with MSIs (see virtio-pci use of kvm functions
directly). The assignment of an irq number for an MSI must be a hook,
probably a PCI controller hook, so x86 can get it done via its existing
kernel interfaces and sane architectures can keep the assignment in qemu
where it belongs.

Cheers,
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

[PATCH v3 0/5] KVM: x86: improve reexecute_instruction

[Xiao Guangrong]

Changlog:
- do not change pte access for mmio access
- a new bug is exposed that Dirty bit is not tracked if CR0.WP = 0
- cache something on page fault path and use them to detect unhandleable
  instruction, suggested by Marcelo

I will add the two testcase for unhandleable instruction after figure
out a way to notify the unemulationable error to guest

--
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 v3 1/5] KVM: MMU: fix Dirty bit missed if CR0.WP = 0

[Xiao Guangrong]

If the write-fault access is from supervisor and CR0.WP is not set on the
vcpu, kvm will fix it by adjusting pte access - it sets the W bit on pte
and clears U bit. This is the chance that kvm can change pte access from
readonly to writable

Unfortunately, the pte access is the access of 'direct' shadow page table,
means direct sp.role.access = pte_access, then we will create a writable
spte entry on the readonly shadow page table. It will cause Dirty bit is
not tracked when two guest ptes point to the same large page. Note, it
does not have other impact except Dirty bit since cr0.wp is encoded into
sp.role

It can be fixed by adjusting pte access before establishing shadow page
table. Also, after that, no mmu specified code exists in the common function
and drop two parameters in set_spte

Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
 arch/x86/kvm/mmu.c |   47 ---
 arch/x86/kvm/paging_tmpl.h |   30 +++
 2 files changed, 38 insertions(+), 39 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 01d7c2a..2a3c890 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2342,8 +2342,7 @@ static int mmu_need_write_protect(struct kvm_vcpu *vcpu, 
gfn_t gfn,
 }

 static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
-   unsigned pte_access, int user_fault,
-   int write_fault, int level,
+   unsigned pte_access, int level,
gfn_t gfn, pfn_t pfn, bool speculative,
bool can_unsync, bool host_writable)
 {
@@ -2378,9 +2377,7 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,

spte |= (u64)pfn  PAGE_SHIFT;

-   if ((pte_access  ACC_WRITE_MASK)
-   || (!vcpu-arch.mmu.direct_map  write_fault
-!is_write_protection(vcpu)  !user_fault)) {
+   if (pte_access  ACC_WRITE_MASK) {

/*
 * There are two cases:
@@ -2399,19 +2396,6 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,

spte |= PT_WRITABLE_MASK | SPTE_MMU_WRITEABLE;

-   if (!vcpu-arch.mmu.direct_map
-!(pte_access  ACC_WRITE_MASK)) {
-   spte = ~PT_USER_MASK;
-   /*
-* If we converted a user page to a kernel page,
-* so that the kernel can write to it when cr0.wp=0,
-* then we should prevent the kernel from executing it
-* if SMEP is enabled.
-*/
-   if (kvm_read_cr4_bits(vcpu, X86_CR4_SMEP))
-   spte |= PT64_NX_MASK;
-   }
-
/*
 * Optimization: for pte sync, if spte was writable the hash
 * lookup is unnecessary (and expensive). Write protection
@@ -2442,18 +2426,15 @@ done:

 static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
 unsigned pt_access, unsigned pte_access,
-int user_fault, int write_fault,
-int *emulate, int level, gfn_t gfn,
-pfn_t pfn, bool speculative,
-bool host_writable)
+int write_fault, int *emulate, int level, gfn_t gfn,
+pfn_t pfn, bool speculative, bool host_writable)
 {
int was_rmapped = 0;
int rmap_count;

-   pgprintk(%s: spte %llx access %x write_fault %d
- user_fault %d gfn %llx\n,
+   pgprintk(%s: spte %llx access %x write_fault %d gfn %llx\n,
 __func__, *sptep, pt_access,
-write_fault, user_fault, gfn);
+write_fault, gfn);

if (is_rmap_spte(*sptep)) {
/*
@@ -2477,9 +2458,8 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 
*sptep,
was_rmapped = 1;
}

-   if (set_spte(vcpu, sptep, pte_access, user_fault, write_fault,
- level, gfn, pfn, speculative, true,
- host_writable)) {
+   if (set_spte(vcpu, sptep, pte_access, level, gfn, pfn, speculative,
+ true, host_writable)) {
if (write_fault)
*emulate = 1;
kvm_mmu_flush_tlb(vcpu);
@@ -2571,10 +2551,9 @@ static int direct_pte_prefetch_many(struct kvm_vcpu 
*vcpu,
return -1;

for (i = 0; i  ret; i++, gfn++, start++)
-   mmu_set_spte(vcpu, start, ACC_ALL,
-access, 0, 0, NULL,
-sp-role.level, gfn,
-page_to_pfn(pages[i]), true, true);
+   mmu_set_spte(vcpu, start, ACC_ALL, access, 0, NULL,
+sp-role.level, gfn, page_to_pfn(pages[i]),
+true, true);

return 0;
 }
@@ -2636,8 +2615,8 

[PATCH v3 2/5] KVM: MMU: fix infinite fault access retry

[Xiao Guangrong]

We have two issues in current code:
- if target gfn is used as its page table, guest will refault then kvm will use
  small page size to map it. We need two #PF to fix its shadow page table

- sometimes, say a exception is triggered during vm-exit caused by #PF
  (see handle_exception() in vmx.c), we remove all the shadow pages shadowed
  by the target gfn before go into page fault path, it will cause infinite
  loop:
  delete shadow pages shadowed by the gfn - try to use large page size to map
  the gfn - retry the access -...

To fix these, we can adjust page size early if the target gfn is used as page
table

Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
 arch/x86/kvm/mmu.c |   13 -
 arch/x86/kvm/paging_tmpl.h |   35 ++-
 2 files changed, 38 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2a3c890..54fc61e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2380,15 +2380,10 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
if (pte_access  ACC_WRITE_MASK) {

/*
-* There are two cases:
-* - the one is other vcpu creates new sp in the window
-*   between mapping_level() and acquiring mmu-lock.
-* - the another case is the new sp is created by itself
-*   (page-fault path) when guest uses the target gfn as
-*   its page table.
-* Both of these cases can be fixed by allowing guest to
-* retry the access, it will refault, then we can establish
-* the mapping by using small page.
+* Other vcpu creates new sp in the window between
+* mapping_level() and acquiring mmu-lock. We can
+* allow guest to retry the access, the mapping can
+* be fixed if guest refault.
 */
if (level  PT_PAGE_TABLE_LEVEL 
has_wrprotected_page(vcpu-kvm, gfn, level))
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index c1e01b6..0453fa0 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -491,6 +491,38 @@ out_gpte_changed:
return 0;
 }

+ /*
+ * To see whether the mapped gfn can write its page table in the current
+ * mapping.
+ *
+ * It is the helper function of FNAME(page_fault). When guest uses large page
+ * size to map the writable gfn which is used as current page table, we should
+ * force kvm to use small page size to map it because new shadow page will be
+ * created when kvm establishes shadow page table that stop kvm using large
+ * page size. Do it early can avoid unnecessary #PF and emulation.
+ *
+ * Note: the PDPT page table is not checked for PAE-32 bit guest. It is ok
+ * since the PDPT is always shadowed, that means, we can not use large page
+ * size to map the gfn which is used as PDPT.
+ */
+static bool
+FNAME(is_self_change_mapping)(struct kvm_vcpu *vcpu,
+ struct guest_walker *walker, int user_fault)
+{
+   int level;
+   gfn_t mask = ~(KVM_PAGES_PER_HPAGE(walker-level) - 1);
+
+   if (!(walker-pte_access  ACC_WRITE_MASK ||
+ (!is_write_protection(vcpu)  !user_fault)))
+   return false;
+
+   for (level = walker-level; level = walker-max_level; level++)
+   if (!((walker-gfn ^ walker-table_gfn[level - 1])  mask))
+   return true;
+
+   return false;
+}
+
 /*
  * Page fault handler.  There are several causes for a page fault:
  *   - there is no shadow pte for the guest pte
@@ -545,7 +577,8 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t 
addr, u32 error_code,
}

if (walker.level = PT_DIRECTORY_LEVEL)
-   force_pt_level = mapping_level_dirty_bitmap(vcpu, walker.gfn);
+   force_pt_level = mapping_level_dirty_bitmap(vcpu, walker.gfn)
+  || FNAME(is_self_change_mapping)(vcpu, walker, user_fault);
else
force_pt_level = 1;
if (!force_pt_level) {
-- 
1.7.7.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

[PATCH v3 3/5] KVM: x86: clean up reexecute_instruction

[Xiao Guangrong]

Little cleanup for reexecute_instruction, also use gpa_to_gfn in
retry_instruction

Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
 arch/x86/kvm/x86.c |   13 ++---
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 76f5446..eccd040 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4761,19 +4761,18 @@ static bool reexecute_instruction(struct kvm_vcpu 
*vcpu, gva_t gva)
if (tdp_enabled)
return false;

+   gpa = kvm_mmu_gva_to_gpa_read(vcpu, gva, NULL);
+   if (gpa == UNMAPPED_GVA)
+   return true; /* let cpu generate fault */
+
/*
 * if emulation was due to access to shadowed page table
 * and it failed try to unshadow page and re-enter the
 * guest to let CPU execute the instruction.
 */
-   if (kvm_mmu_unprotect_page_virt(vcpu, gva))
+   if (kvm_mmu_unprotect_page(vcpu-kvm, gpa_to_gfn(gpa)))
return true;

-   gpa = kvm_mmu_gva_to_gpa_system(vcpu, gva, NULL);
-
-   if (gpa == UNMAPPED_GVA)
-   return true; /* let cpu generate fault */
-
/*
 * Do not retry the unhandleable instruction if it faults on the
 * readonly host memory, otherwise it will goto a infinite loop:
@@ -4828,7 +4827,7 @@ static bool retry_instruction(struct x86_emulate_ctxt 
*ctxt,
if (!vcpu-arch.mmu.direct_map)
gpa = kvm_mmu_gva_to_gpa_write(vcpu, cr2, NULL);

-   kvm_mmu_unprotect_page(vcpu-kvm, gpa  PAGE_SHIFT);
+   kvm_mmu_unprotect_page(vcpu-kvm, gpa_to_gfn(gpa));

return true;
 }
-- 
1.7.7.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

[PATCH v3 4/5] KVM: x86: let reexecute_instruction work for tdp

[Xiao Guangrong]

Currently, reexecute_instruction refused to retry all instructions. If
nested npt is used, the emulation may be caused by shadow page, it can
be fixed by dropping the shadow page

Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
 arch/x86/kvm/x86.c |   19 +--
 1 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index eccd040..bf66169 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4753,17 +4753,24 @@ static int handle_emulation_failure(struct kvm_vcpu 
*vcpu)
return r;
 }

-static bool reexecute_instruction(struct kvm_vcpu *vcpu, gva_t gva)
+static bool reexecute_instruction(struct kvm_vcpu *vcpu, unsigned long cr2)
 {
-   gpa_t gpa;
+   gpa_t gpa = cr2;
pfn_t pfn;
+   unsigned int indirect_shadow_pages;
+
+   spin_lock(vcpu-kvm-mmu_lock);
+   indirect_shadow_pages = vcpu-kvm-arch.indirect_shadow_pages;
+   spin_unlock(vcpu-kvm-mmu_lock);

-   if (tdp_enabled)
+   if (!indirect_shadow_pages)
return false;

-   gpa = kvm_mmu_gva_to_gpa_read(vcpu, gva, NULL);
-   if (gpa == UNMAPPED_GVA)
-   return true; /* let cpu generate fault */
+   if (!vcpu-arch.mmu.direct_map) {
+   gpa = kvm_mmu_gva_to_gpa_read(vcpu, cr2, NULL);
+   if (gpa == UNMAPPED_GVA)
+   return true; /* let cpu generate fault */
+   }

/*
 * if emulation was due to access to shadowed page table
-- 
1.7.7.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

[PATCH v3 5/5] KVM: x86: improve reexecute_instruction

[Xiao Guangrong]

The current reexecute_instruction can not well detect the failed instruction
emulation. It allows guest to retry all the instructions except it accesses
on error pfn

For example, some cases are nested-write-protect - if the page we want to
write is used as PDE but it chains to itself. Under this case, we should
stop the emulation and report the case to userspace

Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
 arch/x86/include/asm/kvm_host.h |7 +
 arch/x86/kvm/paging_tmpl.h  |   23 +++-
 arch/x86/kvm/x86.c  |   58 +--
 3 files changed, 60 insertions(+), 28 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index dc87b65..487f0a1 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -502,6 +502,13 @@ struct kvm_vcpu_arch {
u64 msr_val;
struct gfn_to_hva_cache data;
} pv_eoi;
+
+   /*
+* Cache the access info when fix page fault then use
+* them to detect unhandeable instruction.
+*/
+   gva_t fault_addr;
+   bool target_gfn_is_pt;
 };

 struct kvm_lpage_info {
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 0453fa0..b67fab3 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -506,21 +506,27 @@ out_gpte_changed:
  * size to map the gfn which is used as PDPT.
  */
 static bool
-FNAME(is_self_change_mapping)(struct kvm_vcpu *vcpu,
+FNAME(is_self_change_mapping)(struct kvm_vcpu *vcpu, gva_t addr,
  struct guest_walker *walker, int user_fault)
 {
int level;
gfn_t mask = ~(KVM_PAGES_PER_HPAGE(walker-level) - 1);
+   bool self_changed = false;

if (!(walker-pte_access  ACC_WRITE_MASK ||
  (!is_write_protection(vcpu)  !user_fault)))
return false;

-   for (level = walker-level; level = walker-max_level; level++)
-   if (!((walker-gfn ^ walker-table_gfn[level - 1])  mask))
-   return true;
+   vcpu-arch.fault_addr = addr;

-   return false;
+   for (level = walker-level; level = walker-max_level; level++) {
+   gfn_t gfn = walker-gfn ^ walker-table_gfn[level - 1];
+
+   self_changed |= !(gfn  mask);
+   vcpu-arch.target_gfn_is_pt |= !gfn;
+   }
+
+   return self_changed;
 }

 /*
@@ -548,7 +554,7 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t 
addr, u32 error_code,
int level = PT_PAGE_TABLE_LEVEL;
int force_pt_level;
unsigned long mmu_seq;
-   bool map_writable;
+   bool map_writable, is_self_change_mapping;

pgprintk(%s: addr %lx err %x\n, __func__, addr, error_code);

@@ -576,9 +582,12 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, gva_t 
addr, u32 error_code,
return 0;
}

+   is_self_change_mapping = FNAME(is_self_change_mapping)(vcpu, addr,
+  walker, user_fault);
+
if (walker.level = PT_DIRECTORY_LEVEL)
force_pt_level = mapping_level_dirty_bitmap(vcpu, walker.gfn)
-  || FNAME(is_self_change_mapping)(vcpu, walker, user_fault);
+  || is_self_change_mapping;
else
force_pt_level = 1;
if (!force_pt_level) {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index bf66169..fc33563 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4756,29 +4756,25 @@ static int handle_emulation_failure(struct kvm_vcpu 
*vcpu)
 static bool reexecute_instruction(struct kvm_vcpu *vcpu, unsigned long cr2)
 {
gpa_t gpa = cr2;
+   gfn_t gfn;
pfn_t pfn;
-   unsigned int indirect_shadow_pages;
-
-   spin_lock(vcpu-kvm-mmu_lock);
-   indirect_shadow_pages = vcpu-kvm-arch.indirect_shadow_pages;
-   spin_unlock(vcpu-kvm-mmu_lock);
-
-   if (!indirect_shadow_pages)
-   return false;

if (!vcpu-arch.mmu.direct_map) {
-   gpa = kvm_mmu_gva_to_gpa_read(vcpu, cr2, NULL);
+   /*
+* Write permission should be allowed since only
+* write access need to be emulated.
+*/
+   gpa = kvm_mmu_gva_to_gpa_write(vcpu, cr2, NULL);
+
+   /*
+* If the mapping is invalid in guest, let cpu retry
+* it to generate fault.
+*/
if (gpa == UNMAPPED_GVA)
-   return true; /* let cpu generate fault */
+   return true;
}

-   /*
-* if emulation was due to access to shadowed page table
-* and it failed try to unshadow page and re-enter the
-* guest to let CPU execute the instruction.
-*/
-   if (kvm_mmu_unprotect_page(vcpu-kvm, gpa_to_gfn(gpa)))
-   return true;
+   gfn = 

[PATCH] access: add test for dirty bit tracking if CR0.WP = 0

[Xiao Guangrong]

If the write-fault access is from supervisor and CR0.WP is not set on the
vcpu, kvm will fix it by adjusting pte access - it sets the W bit on pte
and clears U bit. This is the chance that kvm can change pte access from
readonly to writable

Unfortunately, the pte access is the access of 'direct' shadow page table,
means direct sp.role.access = pte_access, then we will create a writable
spte entry on the readonly shadow page table. It will cause Dirty bit is
not tracked when two guest ptes point to the same large page. Note, it
does not have other impact except Dirty bit since cr0.wp is encoded into
sp.role

This testcast is not to to trigger this bug

Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
 x86/access.c |   55 +++
 1 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/x86/access.c b/x86/access.c
index 23a5995..2ca325a 100644
--- a/x86/access.c
+++ b/x86/access.c
@@ -687,6 +687,60 @@ err:
 return 0;
 }

+/*
+ * If the write-fault access is from supervisor and CR0.WP is not set on the
+ * vcpu, kvm will fix it by adjusting pte access - it sets the W bit on pte
+ * and clears U bit. This is the chance that kvm can change pte access from
+ * readonly to writable.
+ *
+ * Unfortunately, the pte access is the access of 'direct' shadow page table,
+ * means direct sp.role.access = pte_access, then we will create a writable
+ * spte entry on the readonly shadow page table. It will cause Dirty bit is
+ * not tracked when two guest ptes point to the same large page. Note, it
+ * does not have other impact except Dirty bit since cr0.wp is encoded into
+ * sp.role.
+ *
+ * Note: to trigger this bug, hugepage should be disabled on host.
+ */
+static int check_large_pte_dirty_for_nowp(ac_pool_t *pool)
+{
+   ac_test_t at1, at2;
+
+   ac_test_init(at1, (void *)(0x12340300));
+   ac_test_init(at2, (void *)(0x0600));
+
+   at2.flags[AC_PDE_PRESENT] = 1;
+   at2.flags[AC_PDE_PSE] = 1;
+
+   ac_test_setup_pte(at2, pool);
+   if (!ac_test_do_access(at2)) {
+   printf(%s: read on the first mapping fail.\n, __FUNCTION__);
+   goto err;
+   }
+
+   at1.flags[AC_PDE_PRESENT] = 1;
+   at1.flags[AC_PDE_PSE] = 1;
+   at1.flags[AC_ACCESS_WRITE] = 1;
+
+   ac_test_setup_pte(at1, pool);
+   if (!ac_test_do_access(at1)) {
+   printf(%s: write on the second mapping fail.\n, __FUNCTION__);
+   goto err;
+   }
+
+   at2.flags[AC_ACCESS_WRITE] = 1;
+   ac_set_expected_status(at2);
+   if (!ac_test_do_access(at2)) {
+   printf(%s: write on the first mapping fail.\n, __FUNCTION__);
+   goto err;
+   }
+
+   return 1;
+
+err:
+   return 0;
+}
+
 static int check_smep_andnot_wp(ac_pool_t *pool)
 {
ac_test_t at1;
@@ -756,6 +810,7 @@ const ac_test_fn ac_test_cases[] =
 {
corrupt_hugepage_triger,
check_pfec_on_prefetch_pte,
+   check_large_pte_dirty_for_nowp,
check_smep_andnot_wp
 };

-- 
1.7.7.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

[PATCH] KVM: PPC: Only WARN on invalid emulation

[Alexander Graf]

When we hit an emulation result that we didn't expect, that is an error,
but it's nothing that warrants a BUG(), because it can be guest triggered.

So instead, let's only WARN() the user that this happened.

Signed-off-by: Alexander Graf ag...@suse.de

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index be83fca..e2225e5 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -237,7 +237,8 @@ int kvmppc_emulate_mmio(struct kvm_run *run, struct 
kvm_vcpu *vcpu)
r = RESUME_HOST;
break;
default:
-   BUG();
+   WARN_ON(1);
+   r = RESUME_GUEST;
}
 
return r;
--
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: [RFC PATCH 0/9] KVM: PPC: In-kernel PAPR interrupt controller emulation

[Alexander Graf]

On 05.11.2012, at 04:18, Paul Mackerras wrote:

 This series implements in-kernel emulation of the XICS interrupt
 controller specified in the PAPR specification and used by pseries
 guests.  Since the XICS is organized a bit differently to the
 interrupt controllers used on x86 machines, I have defined some new
 ioctls for setting up the XICS and for saving and restoring its
 state.  It may be possible to use some of the currently x86-specific
 ioctls instead.

Is this one already following the new world order that we discussed during KVM 
Forum? :)


Alex

 
 Paul.
 --
 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

--
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: [RFC PATCH 0/9] KVM: PPC: In-kernel PAPR interrupt controller emulation

[Benjamin Herrenschmidt]

On Sat, 2012-12-15 at 01:46 +0100, Alexander Graf wrote:
 On 05.11.2012, at 04:18, Paul Mackerras wrote:
 
  This series implements in-kernel emulation of the XICS interrupt
  controller specified in the PAPR specification and used by pseries
  guests.  Since the XICS is organized a bit differently to the
  interrupt controllers used on x86 machines, I have defined some new
  ioctls for setting up the XICS and for saving and restoring its
  state.  It may be possible to use some of the currently x86-specific
  ioctls instead.
 
 Is this one already following the new world order that we discussed during 
 KVM Forum? :)

The new world order  (sorry, looks like nobody took notes and
people expect me to do a write up from memory now ... :-)

Well, mostly we agreed that the x86 stuff wasn't going to work for us.

So basically what we discussed boils down to:

 - Move the existing generic KVM ioctl to create the kernel APIC to
x86 since it's no as-is useful for other archs who, among other things,
might need to pass argument based on the machine type (type of interrupt
subsystem for example, etc...)

 - Once that's done, well, instanciating interrupt controller objects
becomes pretty much an arch specific matter. We could try to keep some
ioctls somewhat common though it's not *that* useful because the various
types  arguments are going to be fairly arch specific, so goes for
configuration. Examples of what could be kept common are:

   * Create irq chip, takes at least a type argument, possibly a few
more type-specific args (or a union, but then let's keep space in there
since we can't change the size of the struct later as it would impact
the ioctl number afaik).

  * Assigning the address of an irq chip when it can change (see ARM
patches)

 - The existing business with irqfd etc... is mostly ok, except the
interfaces messing around with MSIs (see virtio-pci use of kvm functions
directly). The assignment of an irq number for an MSI must be a hook,
probably a PCI controller hook, so x86 can get it done via its existing
kernel interfaces and sane architectures can keep the assignment in qemu
where it belongs.

Cheers,
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