Re: [Xen-devel] Failed vm entry with heavy use of emulator

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 09/07/16 02:31, Tamas K Lengyel wrote:
> On Tue, Jan 5, 2016 at 7:37 AM, Razvan Cojocaru
> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 01/05/2016 04:16 PM, Tamas K Lengyel wrote:
>>>
>>>
>>> On Tue, Jan 5, 2016 at 3:01 PM, Razvan Cojocaru
>>> <rcojocaru@xxxxxxxxxxxxxxx <mailto:rcojocaru@xxxxxxxxxxxxxxx>> wrote:
>>>
>>>     On 01/05/2016 03:49 PM, Andrew Cooper wrote:
>>>     > On 05/01/16 13:39, Razvan Cojocaru wrote:
>>>     >> Here's a quick log of the emulated instructions on my setup:
>>>     >> http://pastebin.com/raw/XXQ0Lnzh
>>>     >
>>>     > Hmm - according to that, the final instruction emulated was
>>>     >
>>>     > d1v0 32bit @ 0008:828925db -> fa
>>>     >
>>>     > which is the 'cli' instruction.
>>>     >
>>>     > I would start there - I doubt it is an instruction which is emulated 
>>> often.
>>>
>>>     My code (arch/x86/x86_emulate/x86_emulate.c) does have a case label
>>>     for it:
>>>
>>>     3677     case 0xfa: /* cli */
>>>     3678         generate_exception_if(!mode_iopl(), EXC_GP, 0);
>>>     3679         _regs.eflags &= ~EFLG_IF;
>>>     3680         break;
>>>
>>>     Maybe the IOPL test fails there? Tamas, does your guest die after a CLI
>>>     as well?
>>>
>>>
>>> I've added a gdprintk(XENLOG_DEBUG, "emulate 0xfa cli\n"); into that
>>> switch case but it wasn't printed before the guest crashed.
>>
>> It's possible that your guest crashes after emulating a different
>> instruction. I've added a line to xen/arch/x86/hvm/emulate.c, in
>> hvm_mem_access_emulate_one():
>>
>> 1790     switch ( kind )
>> 1791     {
>> 1792     case EMUL_KIND_NOWRITE:
>> 1793         rc = hvm_emulate_one_no_write(&ctx);
>> 1794         break;
>> 1795     case EMUL_KIND_SET_CONTEXT:
>> 1796         ctx.set_context = 1;
>> 1797         /* Intentional fall-through. */
>> 1798     default:
>> 1799         rc = hvm_emulate_one(&ctx);
>> 1800         hvm_dump_emulation_state(XENLOG_G_DEBUG, &ctx);
>> 1801     }
>>
>> so I can then see which instruction was the last before the stack trace
>> with xl dmesg (or looking at the log file, etc.)
>>
>> It's possible the problem is not specific to CLI, or maybe it's even
>> something that happens prior to emulating the last instruction that
>> leads to a corruption in the guest's state later on.
>>
> 
> Just a quick update on this issue, I also now see the following
> emulation error when I use xen-access with the emulation response for
> the exec case. The issue previously reported with the failed vm entry
> seem to happen only when emulating in response to the write-access.
> 
> (XEN) Mem event emulation failed: d5v1 32bit @ 0008:826c602c -> 0f 21
> c0 89 82 dc 02 00 00 0f 21 c8 89 82 e0 02
> (XEN) Mem event emulation failed: d5v0 32bit @ 0008:82678caa -> cf 90
> f7 45 70 00 00 02 00 75 09 f7 45 6c 01 00
> (XEN) d5v1 Triple fault - invoking HVM shutdown action
> (XEN) *** Dumping Dom5 vcpu#1 state: ***
> (XEN) ----[ Xen-4.7.0  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    6
> (XEN) RIP:    0008:[<00000000827194f8>]
> (XEN) RFLAGS: 0000000000014292   CONTEXT: hvm guest (d5v1)
> (XEN) rax: 00000000badb10cc   rbx: 00000000807c1534   rcx: 0000000000000000
> (XEN) rdx: 0000000000000000   rsi: 000000008271957f   rdi: 00000000badb10cc
> (XEN) rbp: 00000000807c10e4   rsp: 00000000807c0d30   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 000000008001003b   cr4: 00000000000406f9
> (XEN) cr3: 0000000000185000   cr2: 00000000807c0d2c
> (XEN) ds: 0023   es: 0023   fs: 0030   gs: 0000   ss: 0010   cs: 0008

I see that there were two failed emulation attempts previously (most
likely there's no support in the emulator for the listed instructions).
Does the issue still occur even when there are no failed emulation attempts?

You might try to check and see if the emulation has failed, and if so to
try to run the pending instruction under the MTF and see if this still
occurs. Or, just lift the page restrictions and let the instruction run
if emulation fails. Or, of course, add support for emulating those
instructions.


Cheers,
Razvan

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