fix guest hang

PATCH In review Christoph Egger 2 participants 4 messages Nov 20, 2007

lore

Share & tools

lore

Christoph Egger

author

2007-11-20 12:56 UTC #0 lore raw

PATCH 1/1 fix guest hang

Hi Keir!

Attached patch fixes a boot hang we have seen with SLES 9.3 and FreeBSD HVM guests. Both are 32bit guests and run with a 64bit hypervisor.

The patch does the following:
1) Cache current vcpu in svm_vmexit_do_hlt
2) Check for interrupt shadow in svm_vmexit_do_hlt and handle it like a pending interrupt

The boot hang happens when the hlt is intercepted and the interrupt shadow field in vmcb is set, then the guest waits forever for the next timer interrupt.

Change 1) is a cleanup, 2) is the fix

Signed-off-by Christoph Egger <[email protected]>

Signature · 11 lines

AMD Saxony, Dresden, Germany
Operating System Research Center
Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

xen/arch/x86/hvm/svm/svm.c +8 -6

diff -r d2935f9c217f xen/arch/x86/hvm/svm/svm.c
@@ -1925,20 +1925,22 @@ static void svm_vmexit_do_hlt(struct vmc
 static void svm_vmexit_do_hlt(struct vmcb_struct *vmcb,
                               struct cpu_user_regs *regs)
 {
-    struct hvm_intack intack = hvm_vcpu_has_pending_irq(current);
+    struct vcpu *v = current;
+    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
+    enum hvm_intblk intblk = svm_interrupt_blocked(v, intack);
 
     __update_guest_eip(regs, 1);
 
     /* Check for interrupt not handled or new interrupt. */
     if ( vmcb->eventinj.fields.v ||
-         ((intack.source != hvm_intsrc_none) &&
-          !svm_interrupt_blocked(current, intack)) )
-    {
-        HVMTRACE_1D(HLT, current, /*int pending=*/ 1);
+         (intblk == hvm_intblk_shadow) ||  /* very likely a STI shadow */
+         ((intack.source != hvm_intsrc_none) && (!intblk)) )
+    {
+        HVMTRACE_1D(HLT, v, /*int pending=*/ 1);
         return;
     }
 
-    HVMTRACE_1D(HLT, current, /*int pending=*/ 0);
+    HVMTRACE_1D(HLT, v, /*int pending=*/ 0);
     hvm_hlt(regs->eflags);
 }

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Good catch. Actually I think it is better to clear interrupt_shadow in update_guest_eip. I did this, plus a few other cleanups as c/s 16398 in the unstable staging tree. Please take a look and make sure I didn't screw up.

Thanks,
Keir

Quoted 19 lines · Christoph Egger

Hi Keir!
Attached patch fixes a boot hang we have seen with SLES 9.3 and FreeBSD HVM guests. Both are 32bit guests and run with a 64bit hypervisor.
The patch does the following:
1) Cache current vcpu in svm_vmexit_do_hlt
2) Check for interrupt shadow in svm_vmexit_do_hlt and handle it like a pending interrupt
The boot hang happens when the hlt is intercepted and the interrupt shadow field in vmcb is set, then the guest waits forever for the next timer interrupt.
Change 1) is a cleanup, 2) is the fix
Signed-off-by Christoph Egger <[email protected]>

Christoph Egger

author

2007-11-20 15:29 UTC #2 lore raw

Changeset 16398 is fine with me. Thank you for committing the fix.

Christoph

Quoted 25 lines · On Tuesday 20 November 2007 16:08:32 Keir Fraser wrote:

Good catch. Actually I think it is better to clear interrupt_shadow in update_guest_eip. I did this, plus a few other cleanups as c/s 16398 in the unstable staging tree. Please take a look and make sure I didn't screw up.
Thanks,
Keir
Quoted 17 lines · Christoph Egger
Hi Keir!
Attached patch fixes a boot hang we have seen with SLES 9.3 and FreeBSD HVM guests. Both are 32bit guests and run with a 64bit hypervisor.
The patch does the following:
1) Cache current vcpu in svm_vmexit_do_hlt
2) Check for interrupt shadow in svm_vmexit_do_hlt and handle it like a pending interrupt
The boot hang happens when the hlt is intercepted and the interrupt shadow field in vmcb is set, then the guest waits forever for the next timer interrupt.
Change 1) is a cleanup, 2) is the fix
Signed-off-by Christoph Egger <[email protected]>

Signature · 12 lines

AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Christoph Egger

author

2007-11-20 15:51 UTC #3 lore raw

Quoted 1 line · On Tuesday 20 November 2007 16:29:02 Christoph Egger wrote:

Changeset 16398 is fine with me. Thank you for committing the fix.

At least SLES 9.3 does not hang at boot. We will do more intensive testing.

Quoted 29 lines

Christoph
Quoted 26 lines · On Tuesday 20 November 2007 16:08:32 Keir Fraser wrote:
Good catch. Actually I think it is better to clear interrupt_shadow in update_guest_eip. I did this, plus a few other cleanups as c/s 16398 in the unstable staging tree. Please take a look and make sure I didn't screw up.
Thanks,
Keir
Quoted 17 lines · Christoph Egger
Hi Keir!
Attached patch fixes a boot hang we have seen with SLES 9.3 and FreeBSD HVM guests. Both are 32bit guests and run with a 64bit hypervisor.
The patch does the following:
1) Cache current vcpu in svm_vmexit_do_hlt
2) Check for interrupt shadow in svm_vmexit_do_hlt and handle it like a pending interrupt
The boot hang happens when the hlt is intercepted and the interrupt shadow field in vmcb is set, then the guest waits forever for the next timer interrupt.
Change 1) is a cleanup, 2) is the fix
Signed-off-by Christoph Egger <[email protected]>

Signature · 12 lines

AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy