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

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

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

Tamas

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