[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/x86: ensure copying to L1 guest in update_runstate_area()
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |