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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.02.17 at 03:20, <haozhong.zhang@xxxxxxxxx> wrote:
> 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.

Indeed - that would eliminate all these open coding of assumption
which may be valid at present, but not down the road.

>> > 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

Now that's of course quite odd: The instruction at that address
ought to be a direct far branch, which I think the emulator is able
to deal with. Which leaves the possibility of it fetching the wrong
bytes (which sadly don't get shown above).

Jan


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