The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting all older bugs to
"Incomplete" now.
If you still think this bug report here is valid, then please switch the state
back to "New" within the next 60 days, otherwise this report will be marked as
"Expired". Thank you and sorry for the inconvenience.
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1653419
Title:
SVM emulation fails due to EIP and FLAG register update optimization
Status in QEMU:
Incomplete
Bug description:
SVM emulation support has a bug due to which causes KVM emulation
error when qemu-kvm is run over KVM installed on top of QEmu in
software mode.
Steps to reproduce
1. Run KVM inside QEmu(software mode with SVM emulation support). Make sure
kvm_amd is running.
2. Run any guest OS on top of the KVM using qemu-kvm.
3. Following KVM emulation error is thrown immediately.
KVM internal error. Suberror: 1
emulation failure
EAX= EBX=404b ECX= EDX=000f5ea0
ESI= EDI= EBP= ESP=6fd0
EIP=4000 EFL=0086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00c09300 DPL=0 DS [-WA]
CS =0008 00c09b00 DPL=0 CS32 [-RA]
SS =0010 00c09300 DPL=0 DS [-WA]
DS =0010 00c09300 DPL=0 DS [-WA]
FS =0010 00c09300 DPL=0 DS [-WA]
GS =0010 00c09300 DPL=0 DS [-WA]
LDT= 8200 DPL=0 LDT
TR = 8b00 DPL=0 TSS32-busy
GDT= 000f7180 0037
IDT= 000f71be
CR0=0011 CR2= CR3= CR4=
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EFER=
Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Reason for the error
Due to performance reasons, EIP and FLAG registers are not updated after
executing every guest instructions. There are optimizations done to update
these registers intelligently, for eg: EIP is updated at the end of translation
block. This means EIP remains the address of the first instruction in the TB
throughout the execution.
In case of a VMEXIT because of a page fault happened after executing
an instruction in the middle of the TB, the VMCB is updated with the
wrong guest EIP and jumps to the address where host has left off. On
the subsequent VMRUN by the host QEmu start executing some of the
instructions that has already been executed. This can cause wrong
execution flow.
Following is the instruction execution trace of the above scenario.
0x000f368f: callq 0xeecc4
vmexit(0060, , , 000eecc4)!
vmsave! b72e9000
vmload! b72e9000
vmrun! b72e9000
0x000eecc4: push %rbx
0x000eecc5: xor %ecx,%ecx
0x000eecc7: mov (%rax,%rcx,1),%bl
0x000eecca: cmp (%rdx,%rcx,1),%bl
vmexit(004e, , 000f5ea0, 000eecc4)!
Page fault happens at 0x000eecca which triggers a VMEXIT.
vmcb->save->rip is updated with 0x000eecc4 instead of
0x000eecca.
vmsave! b72e9000
vmload! b72e9000
vmrun! b72e9000
0x000eecc4: push %rbx
0x000eecc5: xor %ecx,%ecx
0x000eecc7: mov (%rax,%rcx,1),%bl
0x000eecca: cmp (%rdx,%rcx,1),%bl
0x000eeccd: je 0xeecdc
0x000eeccf: setl %al
0x000eecd2: movzbl %al,%eax
0x000eecd5: neg %eax
0x000eecd7: or $0x1,%eax
0x000eecda: jmp 0xeece3
0x000eece3: pop %rbx
0x000eece4: retq
vmexit(004e, , 4000, 4000)!
The subsequent VMRUN again starts executing from 0x000eecc4
which causes %rbx being pushed to the stack for the second time. The
retq instruction picks wrong return address and jumps to an illegal
location.
Similar issue is there with updating FLAG register as well.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1653419/+subscriptions
