Re: [Xen-devel] [PATCH] xen/x86: ensure copying to L1 guest in update_runstate_area()

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

On 02/22/17 09:28 +0800, Haozhong Zhang wrote:
> On 02/21/17 02:15 -0700, Jan Beulich wrote:
> > >>> On 21.02.17 at 03:11, <haozhong.zhang@xxxxxxxxx> wrote:
[..] 
> > > +     *
> > > +     * Therefore, we clear the nested guest flag before 
> > > __raw_copy_to_guest()
> > > +     * and __copy_to_guest(), and restore the flag after all guest copy.
> > > +     */
> > > +    if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) )
> >

I think it would be clearer to use nestedhvm_enabled() here.

> > has_hvm_container_vcpu()
> 
> Nested HVM is only available to HVM domain, so I think is_hvm_vcpu(v) is 
> enough.
> 
> > 
> > And why is this HAP-specific?
> >
> 
> IIUC, nested HVM relies on HAP.

For nested SVM, I find the following check in hvmop_set_param():
    case HVM_PARAM_NESTEDHVM:
        if ( cpu_has_svm && !paging_mode_hap(d) && a.value )
            rc = -EINVAL;

I don't find the similar check for nested VMX here and in vvmx.c.
Though L1 HVM domain w/ nestedhvm=1 and hap=0 can boot up on Intel
machine (because of the lack of above check?), starting L2 guest does
crash L1 at the very beginning and L0 Xen reports the following debug
messages:

(XEN) realmode.c:111:d18v9 Failed to emulate insn.
(XEN) Real-mode emulation failed: d18v9 Real @ f000:0000fff0 ->
(XEN) domain_crash called from realmode.c:157
(XEN) Domain 18 (vcpu#9) crashed on cpu#29:
(XEN) ----[ Xen-4.9-unstable  x86_64  debug=y   Not tainted ]----
(XEN) CPU:    29
(XEN) RIP:    f000:[<000000000000fff0>]
(XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest (d18v9)
(XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 0000000000000000
(XEN) rdx: 0000000000000f61   rsi: 0000000000000000   rdi: 0000000000000000
(XEN) rbp: 0000000000000000   rsp: 0000000000000000   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000000000030   cr4: 0000000000002050
(XEN) cr3: 00000000feffc000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: f000

I haven't dug into this problem, but I suspect there would be other
bugs when using nested VMX w/o HAP. Maybe we should add a similar check in
hvmop_set_param() for nested VMX as well.

Kevin, any comments?

Thanks,
Haozhong

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