Issue with 64-bit code execution with kvm enabled

Issue with 64-bit code execution with kvm enabled

[Adhyas Avasthi]

I am trying to boot a 64-bit GRUB2 based EFI Boot Loader on top of
OVMF based EFI BIOS (also 64 bit) for x86_64. My host is Ubuntu 10.04
x86_64 and I am running qemu-kvm-0.13.0 with self-built
kvm-kmod-2.6.32.17 for my kernel version which is 2.6.32-24 (I used
the default Ubuntu KVM and qemu versions with same issue earlier). My
host PC is Lenovo T410 with Intel Core i5

GRUB2 is built with gcc and apparently, EFI has a different calling
convention so GRUB2 has an assembly wrapper file that changes the
parameter as per desired calling convention. The problem is that if I
start the loader with kvm disabled, everything goes fine and their
wrapper instructions do the right thing as well. If I enable kvm,
however, I get an x64 exception (as below):

!!!! X64 Exception Type - 000000000000000D !!!!
ExceptionData - 0000000000000000
RIP - 000000001FFA95FA, RFL - 0000000000010202
RAX - 000000001FF35900, RCX - 0000000000000000, RDX - 000000001FFBB510
RBX - 000000001FF35640, RSP - 000000001FF975C0, RBP - 000000001FFBB510
RSI - 000000001FFBB550, RDI - 000000001FF35940
R8  - 0000000000000000, R9  - 000000001FFBB54F, R10 - 000000001D996FFF
R11 - 000000001FF96EB8, R12 - 000000001FFB6A90, R13 - 0000000000000070
R14 - 000000001D99CFFF, R15 - 0000000000000060
CS  - 0028, DS  - 0008, ES  - 0008, FS  - 0008, GS  - 0008, SS  - 0008
GDT - 000000001FF1CE98; 003F,                   IDT - 000000001FE88BC0; 0FFF
LDT - 0000000000000000, TR  - 0000000000000000
CR0 - 0000000080000023, CR2 - 0000000000000000, CR3 - 000000001FF36000
CR4 - 0000000000000668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400

Here is the call that I am making (and also the target function I am
invoking in EFI):
status = efi_call_4 (b->allocate_pages, type, GRUB_EFI_LOADER_DATA,
pages, &address);
(the target function is:)
EFI_STATUS
EFIAPI
CoreAllocatePages (
  IN EFI_ALLOCATE_TYPE      Type,
  IN EFI_MEMORY_TYPE        MemoryType,
  IN UINTN                  NumberOfPages,
  IN OUT EFI_PHYSICAL_ADDRESS  *Memory
  )

The assembly wrapper that changes as per calling convention in GRUB2 is:

/*
 * x86_64 uses registry to pass parameters. Unfortunately, gcc and efi use
 * different call conversion, so we need to do some conversion.
 *
 * gcc:
 *   %rdi,  %esi,  %rdx,  %rcx, %r8, %r9, 8(%rsp), 16(%rsp), ...
 *
 * efi:
 *   %rcx,  %rdx,  %r8,  %r9,  32(%rsp), 40(%rsp), 48(%rsp), ...
 *
 */
FUNCTION(efi_wrap_4)
        subq $40, %rsp
        mov %r8, %r9
        mov %rcx, %r8
        mov %rsi, %rcx
        call *%rdi
        addq $40, %rsp
        ret


Is this a bug? How can the same piece of code work fine on pure qemu
emulation and not on kvm mode?
I will appreciate if someone can throw more light on this issue I am facing.

Thanks,
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
    — ANSI C Standard, 3.1.2.6.
********************************************************************

Re: Issue with 64-bit code execution with kvm enabled

[Adhyas Avasthi]

[-- Attachment #1: Type: text/plain, Size: 4400 bytes --]

An alternate implementation of the efi_wrap_4 function has the same
issue. Here is the alternate function I found from another Unix to EFI
calling wrapper, which is part of the EFI BIOS code base.

 movq    %rdi, %rax    // Swizzle args
 movq    %rsi, %r9
//  movq    %rdx, %rdx
 movq    %rcx, %r8
 movq    %r9,  %rcx

       subq  $40, %rsp              // 32-byte shadow space plus alignment pad
       call    *%rax
 addq  $40, %rsp

       ret

This works in pure emulation without kvm, but gives me an exception
with kvm enabled.
I don't quite understand what may have caused this. Perhaps this is a
naive question, but how good is kvm for recent 64 bit Intel CPUs ? I
have also attached my host's cpuinfo output if that helps.

Thanks,
Adhyas

On Sat, Nov 13, 2010 at 3:37 PM, Adhyas Avasthi <adhyas@gmail.com> wrote:
> I am trying to boot a 64-bit GRUB2 based EFI Boot Loader on top of
> OVMF based EFI BIOS (also 64 bit) for x86_64. My host is Ubuntu 10.04
> x86_64 and I am running qemu-kvm-0.13.0 with self-built
> kvm-kmod-2.6.32.17 for my kernel version which is 2.6.32-24 (I used
> the default Ubuntu KVM and qemu versions with same issue earlier). My
> host PC is Lenovo T410 with Intel Core i5
>
> GRUB2 is built with gcc and apparently, EFI has a different calling
> convention so GRUB2 has an assembly wrapper file that changes the
> parameter as per desired calling convention. The problem is that if I
> start the loader with kvm disabled, everything goes fine and their
> wrapper instructions do the right thing as well. If I enable kvm,
> however, I get an x64 exception (as below):
>
> !!!! X64 Exception Type - 000000000000000D !!!!
> ExceptionData - 0000000000000000
> RIP - 000000001FFA95FA, RFL - 0000000000010202
> RAX - 000000001FF35900, RCX - 0000000000000000, RDX - 000000001FFBB510
> RBX - 000000001FF35640, RSP - 000000001FF975C0, RBP - 000000001FFBB510
> RSI - 000000001FFBB550, RDI - 000000001FF35940
> R8  - 0000000000000000, R9  - 000000001FFBB54F, R10 - 000000001D996FFF
> R11 - 000000001FF96EB8, R12 - 000000001FFB6A90, R13 - 0000000000000070
> R14 - 000000001D99CFFF, R15 - 0000000000000060
> CS  - 0028, DS  - 0008, ES  - 0008, FS  - 0008, GS  - 0008, SS  - 0008
> GDT - 000000001FF1CE98; 003F,                   IDT - 000000001FE88BC0; 0FFF
> LDT - 0000000000000000, TR  - 0000000000000000
> CR0 - 0000000080000023, CR2 - 0000000000000000, CR3 - 000000001FF36000
> CR4 - 0000000000000668, CR8 - 0000000000000000
> DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
> DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
>
> Here is the call that I am making (and also the target function I am
> invoking in EFI):
> status = efi_call_4 (b->allocate_pages, type, GRUB_EFI_LOADER_DATA,
> pages, &address);
> (the target function is:)
> EFI_STATUS
> EFIAPI
> CoreAllocatePages (
>  IN EFI_ALLOCATE_TYPE      Type,
>  IN EFI_MEMORY_TYPE        MemoryType,
>  IN UINTN                  NumberOfPages,
>  IN OUT EFI_PHYSICAL_ADDRESS  *Memory
>  )
>
> The assembly wrapper that changes as per calling convention in GRUB2 is:
>
> /*
>  * x86_64 uses registry to pass parameters. Unfortunately, gcc and efi use
>  * different call conversion, so we need to do some conversion.
>  *
>  * gcc:
>  *   %rdi,  %esi,  %rdx,  %rcx, %r8, %r9, 8(%rsp), 16(%rsp), ...
>  *
>  * efi:
>  *   %rcx,  %rdx,  %r8,  %r9,  32(%rsp), 40(%rsp), 48(%rsp), ...
>  *
>  */
> FUNCTION(efi_wrap_4)
>        subq $40, %rsp
>        mov %r8, %r9
>        mov %rcx, %r8
>        mov %rsi, %rcx
>        call *%rdi
>        addq $40, %rsp
>        ret
>
>
> Is this a bug? How can the same piece of code work fine on pure qemu
> emulation and not on kvm mode?
> I will appreciate if someone can throw more light on this issue I am facing.
>
> Thanks,
> Adhyas
> ********************************************************************
> Two types have compatible type if their types are the same.
>     — ANSI C Standard, 3.1.2.6.
> ********************************************************************
>



-- 
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
    — ANSI C Standard, 3.1.2.6.
********************************************************************

[-- Attachment #2: cpuinfo --]
[-- Type: application/octet-stream, Size: 1666 bytes --]

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 37
model name	: Intel(R) Core(TM) i5 CPU       M 520  @ 2.40GHz
stepping	: 2
cpu MHz		: 1199.000
cache size	: 3072 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4787.40
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 37
model name	: Intel(R) Core(TM) i5 CPU       M 520  @ 2.40GHz
stepping	: 2
cpu MHz		: 1199.000
cache size	: 3072 KB
physical id	: 0
siblings	: 2
core id		: 2
cpu cores	: 2
apicid		: 4
initial apicid	: 4
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4787.40
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Re: Issue with 64-bit code execution with kvm enabled

[Adhyas Avasthi]

Some more debug information (if it helps someone analyze my problem
and suggest a solution).
I changed the wrapper code to hang just before making the call. And
here is the modified wrapper:

FUNCTION(efi_wrap_4_with_hang)
       subq $40, %rsp
       mov %r8, %r9
       mov %rcx, %r8
       mov %rsi, %rcx
efi_wrap_4_hang:
       jmp   efi_wrap_4_hang
       call *%rdi
       addq $40, %rsp
       ret

I am not making the call as:

efi_call_4 (b->allocate_pages, type, GRUB_EFI_LOADER_DATA, pages, &address);

#define efi_call_4(func, a, b, c, d) \
 efi_wrap_4(func, (grub_uint64_t) a, (grub_uint64_t) b, (grub_uint64_t) c, \
 (grub_uint64_t) d)

The target of the call is (and the calling convention is as per EFI
requirements):
And the target is:
EFI_STATUS
EFIAPI
CoreAllocatePages (
 IN EFI_ALLOCATE_TYPE      Type,
 IN EFI_MEMORY_TYPE        MemoryType,
 IN UINTN                  NumberOfPages,
 IN OUT EFI_PHYSICAL_ADDRESS  *Memory
 )

The register dump at the hang-ed point for both kvm-enabled and
kvm-disabled is as below. Note that the code seems to work for
kvm-disabled case but issues an exception for kvm-enabled case. That
is the issue I am facing.

(With KVM enabled, code issues exception, register layout at hang is):
(qemu) info registers
RAX=000000001ff34f18 RBX=0000000000000006 RCX=0000000000000000
RDX=0000000000000002
RSI=0000000000000000 RDI=000000001ff9a504 RBP=000000001d9a4285
RSP=000000001ff97708
R8 =0000000000000006 R9 =000000001ff97740 R10=0000000000000010
R11=0000000000000009
R12=000000001ffb5960 R13=000000001ff97740 R14=0000000000000000
R15=000000001d99d750
RIP=000000001d99d75d RFL=00000212 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0008 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
CS =0028 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA]
SS =0008 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0008 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
FS =0008 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
GS =0008 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     000000001ff1ce98 0000003f
IDT=     000000001fe88bc0 00000fff
CR0=80000023 CR2=0000000000000000 CR3=000000001ff36000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000500
FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000

The working case (with kvm disabled), register layout at hang:
(qemu) info registers
RAX=000000001ff34f18 RBX=0000000000000006 RCX=0000000000000000
RDX=0000000000000002
RSI=0000000000000000 RDI=000000001ff9a504 RBP=000000001d9a4285
RSP=000000001ff97708
R8 =0000000000000006 R9 =000000001ff97740 R10=0000000000000010
R11=0000000000000009
R12=000000001ffb5960 R13=000000001ff97740 R14=0000000000000000
R15=000000001d99d750
RIP=000000001d99d75d RFL=00000212 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0028 0000000000000000 ffffffff 00af9b00 DPL=0 CS64 [-RA]
SS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     000000001ff1ce98 0000003f
IDT=     000000001fe88bc0 00000fff
CR0=80000033 CR2=0000000000000000 CR3=000000001ff36000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000500
FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000

Does that give someone an idea as to what may be going wrong? I will
try to debug it further to root cause the issue.

Thanks,
Adhyas

On Sat, Nov 13, 2010 at 10:22 PM, Adhyas Avasthi <adhyas@gmail.com> wrote:
> An alternate implementation of the efi_wrap_4 function has the same
> issue. Here is the alternate function I found from another Unix to EFI
> calling wrapper, which is part of the EFI BIOS code base.
>
>  movq    %rdi, %rax    // Swizzle args
>  movq    %rsi, %r9
> //  movq    %rdx, %rdx
>  movq    %rcx, %r8
>  movq    %r9,  %rcx
>
>       subq  $40, %rsp              // 32-byte shadow space plus alignment pad
>       call    *%rax
>  addq  $40, %rsp
>
>       ret
>
> This works in pure emulation without kvm, but gives me an exception
> with kvm enabled.
> I don't quite understand what may have caused this. Perhaps this is a
> naive question, but how good is kvm for recent 64 bit Intel CPUs ? I
> have also attached my host's cpuinfo output if that helps.
>
> Thanks,
> Adhyas
>
> On Sat, Nov 13, 2010 at 3:37 PM, Adhyas Avasthi <adhyas@gmail.com> wrote:
>> I am trying to boot a 64-bit GRUB2 based EFI Boot Loader on top of
>> OVMF based EFI BIOS (also 64 bit) for x86_64. My host is Ubuntu 10.04
>> x86_64 and I am running qemu-kvm-0.13.0 with self-built
>> kvm-kmod-2.6.32.17 for my kernel version which is 2.6.32-24 (I used
>> the default Ubuntu KVM and qemu versions with same issue earlier). My
>> host PC is Lenovo T410 with Intel Core i5
>>
>> GRUB2 is built with gcc and apparently, EFI has a different calling
>> convention so GRUB2 has an assembly wrapper file that changes the
>> parameter as per desired calling convention. The problem is that if I
>> start the loader with kvm disabled, everything goes fine and their
>> wrapper instructions do the right thing as well. If I enable kvm,
>> however, I get an x64 exception (as below):
>>
>> !!!! X64 Exception Type - 000000000000000D !!!!
>> ExceptionData - 0000000000000000
>> RIP - 000000001FFA95FA, RFL - 0000000000010202
>> RAX - 000000001FF35900, RCX - 0000000000000000, RDX - 000000001FFBB510
>> RBX - 000000001FF35640, RSP - 000000001FF975C0, RBP - 000000001FFBB510
>> RSI - 000000001FFBB550, RDI - 000000001FF35940
>> R8  - 0000000000000000, R9  - 000000001FFBB54F, R10 - 000000001D996FFF
>> R11 - 000000001FF96EB8, R12 - 000000001FFB6A90, R13 - 0000000000000070
>> R14 - 000000001D99CFFF, R15 - 0000000000000060
>> CS  - 0028, DS  - 0008, ES  - 0008, FS  - 0008, GS  - 0008, SS  - 0008
>> GDT - 000000001FF1CE98; 003F,                   IDT - 000000001FE88BC0; 0FFF
>> LDT - 0000000000000000, TR  - 0000000000000000
>> CR0 - 0000000080000023, CR2 - 0000000000000000, CR3 - 000000001FF36000
>> CR4 - 0000000000000668, CR8 - 0000000000000000
>> DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
>> DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
>>
>> Here is the call that I am making (and also the target function I am
>> invoking in EFI):
>> status = efi_call_4 (b->allocate_pages, type, GRUB_EFI_LOADER_DATA,
>> pages, &address);
>> (the target function is:)
>> EFI_STATUS
>> EFIAPI
>> CoreAllocatePages (
>>  IN EFI_ALLOCATE_TYPE      Type,
>>  IN EFI_MEMORY_TYPE        MemoryType,
>>  IN UINTN                  NumberOfPages,
>>  IN OUT EFI_PHYSICAL_ADDRESS  *Memory
>>  )
>>
>> The assembly wrapper that changes as per calling convention in GRUB2 is:
>>
>> /*
>>  * x86_64 uses registry to pass parameters. Unfortunately, gcc and efi use
>>  * different call conversion, so we need to do some conversion.
>>  *
>>  * gcc:
>>  *   %rdi,  %esi,  %rdx,  %rcx, %r8, %r9, 8(%rsp), 16(%rsp), ...
>>  *
>>  * efi:
>>  *   %rcx,  %rdx,  %r8,  %r9,  32(%rsp), 40(%rsp), 48(%rsp), ...
>>  *
>>  */
>> FUNCTION(efi_wrap_4)
>>        subq $40, %rsp
>>        mov %r8, %r9
>>        mov %rcx, %r8
>>        mov %rsi, %rcx
>>        call *%rdi
>>        addq $40, %rsp
>>        ret
>>
>>
>> Is this a bug? How can the same piece of code work fine on pure qemu
>> emulation and not on kvm mode?
>> I will appreciate if someone can throw more light on this issue I am facing.
>>
>> Thanks,
>> Adhyas
>> ********************************************************************
>> Two types have compatible type if their types are the same.
>>     — ANSI C Standard, 3.1.2.6.
>> ********************************************************************
>>
>
>
>
> --
> Adhyas
> ********************************************************************
> Two types have compatible type if their types are the same.
>     — ANSI C Standard, 3.1.2.6.
> ********************************************************************
>



-- 
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
    — ANSI C Standard, 3.1.2.6.
********************************************************************

Re: Issue with 64-bit code execution with kvm enabled

[Gleb Natapov]

On Sat, Nov 13, 2010 at 03:37:14PM -0800, Adhyas Avasthi wrote:
> I am trying to boot a 64-bit GRUB2 based EFI Boot Loader on top of
> OVMF based EFI BIOS (also 64 bit) for x86_64. My host is Ubuntu 10.04
> x86_64 and I am running qemu-kvm-0.13.0 with self-built
> kvm-kmod-2.6.32.17 for my kernel version which is 2.6.32-24 (I used
> the default Ubuntu KVM and qemu versions with same issue earlier). My
> host PC is Lenovo T410 with Intel Core i5
> 
> GRUB2 is built with gcc and apparently, EFI has a different calling
> convention so GRUB2 has an assembly wrapper file that changes the
> parameter as per desired calling convention. The problem is that if I
> start the loader with kvm disabled, everything goes fine and their
> wrapper instructions do the right thing as well. If I enable kvm,
> however, I get an x64 exception (as below):
> 
> !!!! X64 Exception Type - 000000000000000D !!!!
> ExceptionData - 0000000000000000
> RIP - 000000001FFA95FA, RFL - 0000000000010202
Can you disassemble code around the RIP?
Also provide ftrace of kvm execution during the failure.

--
			Gleb.