[Xen-devel] [PATCH for-4.5] x86/HVM: Partial revert of 28b4baacd5

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

A failed vmentry is overwhelmingly likely to be caused by corrupt VMCS state.
As a result, injecting a fault and retrying the the vmentry is likely to fail
in the same way.

While crashing a guest because userspace tickled a hypervisor bug to get up
invalid VMCS state is bad (and usually warrants an XSA), it is better than the
infinite loop caused by this change, and the non-ratelimited console output it
would cause.

Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CC: Keir Fraser <keir@xxxxxxx>
CC: Jan Beulich <JBeulich@xxxxxxxx>
CC: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

---

Konrad: A hypervisor infinite loop is quite bad, so I am requesting a release
ack for this.  An alternative would be to revert 28b4baacd5 wholesale, but
most of it is good.

One other alternative, which I would pursue if we were not already in -rc2
would be to add some extra logic to detect repeated vmentry failure and allow
one attempt to shoot userspace before giving up and crashing the domain.
---
 xen/arch/x86/hvm/vmx/vmx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2907afa..9b98595 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2520,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned int exit_reason,
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
 
-    vmx_crash_or_fault(curr);
+    domain_crash(curr->domain);
 }
 
 void vmx_enter_realmode(struct cpu_user_regs *regs)
-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel