Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault

[<Kevin.Mayer@xxxxxxxx>]

vmx_vmenter_helper is not part of the call stack. The address is simply the 
location of the ud2 to which the 
__vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);
In
static void vmx_fpu_leave(struct vcpu *v)
jumps.
There are two vmwrites in vmx_vcpu_update_eptp (called by altp2m_vcpu_destroy):
__vmwrite(EPT_POINTER, ept_get_eptp(ept));
__vmwrite(EPTP_INDEX, vcpu_altp2m(v).p2midx);

And four in vmx_vcpu_update_vmfunc_ve (also called by altp2m_vcpu_destroy)
__vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);
__vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
__vmwrite(VIRT_EXCEPTION_INFO, mfn_x(mfn) << PAGE_SHIFT);
__vmwrite(SECONDARY_VM_EXEC_CONTROL,  v->arch.hvm_vmx.secondary_exec_control);

After the altp2m-part hvm_vcpu_destroy also calls nestedhvm_vcpu_destroy(v), 
but this code path is executed unconditionally so I assume that the error lies 
somewhere in the altp2m_vcpu_destroy(v).

What exactly are the vmx_vmcs_enter / exit required for? I often see the 
vmx_vmcs_enter; __vmwrite; vmx_vmcs_exit combination. Need the __vmwrites be 
guarded by an enter / exit ( which Is not the case in the static void 
vmx_fpu_leave(struct vcpu *v) )?
Is it possible that the 
altp2m_vcpu_destroy->vmx_vcpu_update_eptp->vmx_vmcs_exit->vmx_clear_vmcs 
invalidates the vmcs for the current vcpu?

Cheers

Kevin

> -----Ursprüngliche Nachricht-----
> Von: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Gesendet: Freitag, 5. August 2016 16:49
> An: Mayer, Kevin <Kevin.Mayer@xxxxxxxx>
> Cc: andrew.cooper3@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx
> Betreff: Re: AW: AW: AW: [Xen-devel] Xen 4.6.1 crash with altp2m enabled
> bydefault
> 
> >>> On 05.08.16 at 14:51, <Kevin.Mayer@xxxxxxxx> wrote:
> > According to the xen dmesg
> >
> > (XEN) RIP:    e008:[<ffff82d0801fd23a>]
> vmx_vmenter_helper+0x27e/0x30a
> > (XEN) RFLAGS: 0000000000010003   CONTEXT: hypervisor
> > (XEN) rax: 000000008005003b   rbx: ffff8300e72fc000   rcx:
> 0000000000000000
> > (XEN) rdx: 0000000000006c00   rsi: ffff830617fd7fc0   rdi: ffff8300e6fc0000
> > (XEN) rbp: ffff830617fd7c40   rsp: ffff830617fd7c30   r8:  0000000000000000
> > (XEN) r9:  ffff830be8dc9310   r10: 0000000000000000   r11: 00003475e9cf85d0
> > (XEN) r12: 0000000000000006   r13: ffff830c14ee1000   r14: ffff8300e6fc0000
> > (XEN) r15: ffff830617fd0000   cr0: 000000008005003b   cr4:
> 00000000000026e0
> > (XEN) cr3: 00000001bd665000   cr2: 0000000004510000
> > (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> >
> > 0xffff82d0801fa0c3 <vmx_ctxt_switch_from+85>:        mov    $0x6c00,%edx
> > 0xffff82d0801fa0c8 <vmx_ctxt_switch_from+90>:        vmwrite %rax,%rdx
> >
> > The vmwrite tries to write 0x000000008005003b   to 0x6c00.
> > But the active VCPU has a 0-vmcs-pointer.
> 
> Which likely means altp2m manages to confuse some of VMX'es VMCS
> management - vmx_vmenter_helper() being on the path back to the guest,
> it should be impossible for the VMCS pointer to be zero here. Can you
> perhaps identify the most recent vmread or vmwrite which worked fine?
> There ought to be many on that path, and the state corruption could then
> perhaps be narrowed to quite small a range of code.
> 
> Jan
____________
Virus checked by G Data MailSecurity
Version: AVA 25.7794 dated 08.08.2016
Virus news: www.antiviruslab.com

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