Fixed KVM problems with old DOS programs. Compatibility can be forced by module parameter.

PATCH In review Gerhard Wiesinger 2 participants 7 messages Nov 4, 2015 – Nov 5, 2015

Subsystems (3)

x86 KVM KVM x86

lore

Share & tools

lore

Gerhard Wiesinger

author

2015-11-04 19:38 UTC #0 lore raw

PATCH 1/1 Fixed KVM problems with old DOS programs. Compatibility can be forced by module parameter.

Signed-off-by Gerhard Wiesinger <[email protected]>

---
 arch/x86/kvm/svm.c | 7 +++++++
 1 file changed, 7 insertions(+)

arch/x86/kvm/svm.c +6 -0

index 2f9ed1f..e0b00fc 100644
@@ -198,6 +198,10 @@ static bool npt_enabled;
 static int npt = true;
 module_param(npt, int, S_IRUGO);
 +/* allow backward compatibility with e.g. old DOS application */
+static int npt_task_switch_emulation = true;
+module_param(npt_task_switch_emulation, int, S_IRUGO);
+
 /* allow nested virtualization in KVM/SVM */
 static int nested = true;
 module_param(nested, int, S_IRUGO);

@@ -1177,6 +1181,9 @@ static void init_vmcb(struct vcpu_svm *svm, bool init_event)
 	if (npt_enabled) {
 		/* Setup VMCB for Nested Paging */
 		control->nested_ctl = 1;
+		if (!npt_task_switch_emulation) {
+			clr_intercept(svm, INTERCEPT_TASK_SWITCH);
+		}
 		clr_intercept(svm, INTERCEPT_INVLPG);
 		clr_exception_intercept(svm, PF_VECTOR);
 		clr_cr_intercept(svm, INTERCEPT_CR3_READ);

Signature · 1 line

2.4.3

Paolo Bonzini

maintainer

2015-11-04 21:27 UTC #1 lore raw

Quoted 29 lines · Gerhard Wiesinger

Signed-off-by Gerhard Wiesinger <[email protected]>

---
 arch/x86/kvm/svm.c | 7 +++++++
 1 file changed, 7 insertions(+)

arch/x86/kvm/svm.c +6 -0

index 2f9ed1f..e0b00fc 100644
@@ -198,6 +198,10 @@ static bool npt_enabled;
 static int npt = true;
 module_param(npt, int, S_IRUGO);
 +/* allow backward compatibility with e.g. old DOS application */
+static int npt_task_switch_emulation = true;
+module_param(npt_task_switch_emulation, int, S_IRUGO);
+
 /* allow nested virtualization in KVM/SVM */
 static int nested = true;
 module_param(nested, int, S_IRUGO);

@@ -1177,6 +1181,9 @@ static void init_vmcb(struct vcpu_svm *svm, bool
 init_event)
     if (npt_enabled) {
         /* Setup VMCB for Nested Paging */
         control->nested_ctl = 1;
+        if (!npt_task_switch_emulation) {
+            clr_intercept(svm, INTERCEPT_TASK_SWITCH);
+        }
         clr_intercept(svm, INTERCEPT_INVLPG);
         clr_exception_intercept(svm, PF_VECTOR);

Quoted 1 line

         clr_cr_intercept(svm, INTERCEPT_CR3_READ);

What is the problem you are seeing? KVM can emulate task switches; the intercept is set here because of a processor erratum that can mess them up even though, in theory, AMD supports task switching from guest mode.

Paolo

Gerhard Wiesinger

author

2015-11-04 21:33 UTC #2 lore raw

Quoted 27 lines · Paolo Bonzini

Quoted 25 lines · Gerhard Wiesinger

Signed-off-by Gerhard Wiesinger <[email protected]>

---
  arch/x86/kvm/svm.c | 7 +++++++
  1 file changed, 7 insertions(+)

arch/x86/kvm/svm.c +4 -0

index 2f9ed1f..e0b00fc 100644
@@ -198,6 +198,10 @@ static bool npt_enabled;
  static int npt = true;
  module_param(npt, int, S_IRUGO);
  +/* allow backward compatibility with e.g. old DOS application */
+static int npt_task_switch_emulation = true;
+module_param(npt_task_switch_emulation, int, S_IRUGO);
+
  /* allow nested virtualization in KVM/SVM */
  static int nested = true;
  module_param(nested, int, S_IRUGO);

@@ -1177,6 +1181,9 @@ static void init_vmcb(struct vcpu_svm *svm, bool
 init_event)
      if (npt_enabled) {
          /* Setup VMCB for Nested Paging */
          control->nested_ctl = 1;
+        if (!npt_task_switch_emulation) {

Quoted 8 lines

Quoted 5 lines
arch/x86/kvm/svm.c +2 -0
+            clr_intercept(svm, INTERCEPT_TASK_SWITCH);
+        }
          clr_intercept(svm, INTERCEPT_INVLPG);
          clr_exception_intercept(svm, PF_VECTOR);
          clr_cr_intercept(svm, INTERCEPT_CR3_READ);
What is the problem you are seeing? KVM can emulate task switches; the intercept is set here because of a processor erratum that can mess them up even though, in theory, AMD supports task switching from guest mode.

See old thread:
https://lists.nongnu.org/archive/html/qemu-devel/2012-04/msg01506.html

Ciao,
Gerhard

Paolo Bonzini

maintainer

2015-11-04 22:04 UTC #3 lore raw

Quoted 7 lines · Gerhard Wiesinger

Quoted 4 lines
Quoted 1 line
What is the problem you are seeing? KVM can emulate task switches; the intercept is set here because of a processor erratum that can mess them up even though, in theory, AMD supports task switching from guest mode.
See old thread:
https://lists.nongnu.org/archive/html/qemu-devel/2012-04/msg01506.html

Can you obtain the traces you were asked for at the time?

Paolo

Gerhard Wiesinger

author

2015-11-05 16:07 UTC #4 lore raw

Quoted 8 lines · Paolo Bonzini

Quoted 5 lines · Gerhard Wiesinger
Quoted 3 lines
What is the problem you are seeing? KVM can emulate task switches; the intercept is set here because of a processor erratum that can mess them up even though, in theory, AMD supports task switching from guest mode.
See old thread:
https://lists.nongnu.org/archive/html/qemu-devel/2012-04/msg01506.html
Can you obtain the traces you were asked for at the time?

./trace-cmd record -b 20000 -e kvm
./trace-cmd report | grep -i task_switch
qemu-system-x86-6024 [001] 792774.719297: kvm_exit: reason
task_switch rip 0x4883 info 158 4000000000

But I can't interpret it. But I know my patch works well. Since it is just a module parameter it is fully backward compatible by default and because of the one liner no side effects are possible. So a intergration would be good.

Ciao,
Gerhard

Paolo Bonzini

maintainer

2015-11-05 16:15 UTC #5 lore raw

Quoted 6 lines · Gerhard Wiesinger

Quoted 1 line
./trace-cmd record -b 20000 -e kvm
./trace-cmd report | grep -i task_switch
qemu-system-x86-6024 [001] 792774.719297: kvm_exit: reason task_switch
rip 0x4883 info 158 4000000000

0x158 is the segment selector of the incoming TSS, and the task switch was caused by a far jump.

Quoted 1 line

But I can't interpret it.

Neither can I; you have to send the whole trace.

Quoted 4 lines

But I know my patch works well. Since it is
just a module parameter it is fully backward compatible by default and because of the one liner no side effects are possible. So a intergration would be good.

It's also papering over a bug, and likely the bug still triggers on Intel systems. So it's not acceptable.

Can you provide reproduction instructions please?

Paolo

Paolo Bonzini

maintainer

2015-11-05 16:19 UTC #6 lore raw

Quoted 22 lines · Paolo Bonzini

Quoted 6 lines · Gerhard Wiesinger
Quoted 1 line
./trace-cmd record -b 20000 -e kvm
./trace-cmd report | grep -i task_switch
qemu-system-x86-6024 [001] 792774.719297: kvm_exit: reason task_switch
rip 0x4883 info 158 4000000000
0x158 is the segment selector of the incoming TSS, and the task switch was caused by a far jump.
Quoted 1 line
But I can't interpret it.
Neither can I; you have to send the whole trace.
Quoted 4 lines
But I know my patch works well. Since it is
just a module parameter it is fully backward compatible by default and because of the one liner no side effects are possible. So a intergration would be good.

Quoted 4 lines

It's also papering over a bug, and likely the bug still triggers on Intel systems. So it's not acceptable.
Can you provide reproduction instructions please?

At the very least, does it reproduce without KVM?

Paolo