Bug 848328 - kvm emulates instructions with rip-relative addressing incorrectly
kvm emulates instructions with rip-relative addressing incorrectly
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.4
x86_64 Linux
unspecified Severity low
: rc
: ---
Assigned To: Andrew Jones
Virtualization Bugs
:
Depends On: 848325
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-15 05:34 EDT by Avi Kivity
Modified: 2013-04-22 12:02 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 848325
Environment:
Last Closed: 2013-04-18 03:18:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Avi Kivity 2012-08-15 05:34:56 EDT
+++ This bug was initially created as a clone of Bug #848325 +++

Description of problem:

The KVM x86 emulator does calculates rip-relative addresses incorrectly: if they contain an immediate operand, then the memory operand's address will be off by the size of the immediate operand.

Example:

  movl $0, somewhere(%rip)

Version-Release number of selected component (if applicable):
kvm-83-259.el5

How reproducible:
Never

Steps to Reproduce:
1. Find a guest which accesses mmio using an rip-relative instruction with an immediate
2. Run guest
3. Watch guest malfunction
  
Actual results:

Guest malfunctions

Expected results:

Guest works correctly

Additional info:

--- Additional comment from avi@redhat.com on 2012-08-15 12:33:58 IDT ---

Upstream fix:

commit cb16c348760ad2bc79b67b20aefac05529569ed7
Author: Avi Kivity <avi@redhat.com>
Date:   Sun Jun 19 19:21:11 2011 +0300

    KVM: x86 emulator: fix %rip-relative addressing with immediate source operand
    
    %rip-relative addressing is relative to the first byte of the next instruction,
    so we need to add %rip only after we've fetched any immediate bytes.
    
    Based on original patch by Li Xin <xin.li@intel.com>.
    
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Acked-by: Li Xin <xin.li@intel.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Comment 3 Andrew Jones 2013-04-02 09:48:23 EDT
afaict, rhel6 doesn't need this patch. rhel6's arch/x86/kvm/emulate.c is missing 69f55cb11e8d78, which was the patch that moved the 'effective address += rip' up above the immediate fetching. Thus, we shouldn't have to move it back down again (which is what cb16c348760ad does).

Setting needinfo on Gleb to ack that analysis. If acked we can close as NOTABUG.
Comment 4 Gleb Natapov 2013-04-18 02:03:18 EDT
Yes, it looks like you are correct. Good thing we have a unit test for this case now. You can run emulator.flat to be absolutely sure.
Comment 5 Andrew Jones 2013-04-22 12:02:20 EDT
(In reply to comment #4)
> Yes, it looks like you are correct. Good thing we have a unit test for this
> case now. You can run emulator.flat to be absolutely sure.

Thanks for the pointer. I ran it and the rip_relative test passed.

Note You need to log in before you can comment on or make changes to this bug.