Branch: refs/heads/next
Home: https://github.com/siemens/jailhouse
Commit: 23766cddc2c5fe7e9a5cfb3db430cd14aa5315c2
https://github.com/siemens/jailhouse/commit/23766cddc2c5fe7e9a5cfb3db430cd14aa5315c2
Author: Ralf Ramsauer <[email protected]>
Date: 2019-06-13 (Thu, 13 Jun 2019)
Changed paths:
M hypervisor/arch/x86/mmio.c
M inmates/tests/x86/mmio-access-32.c
M inmates/tests/x86/mmio-access.c
Log Message:
-----------
x86: mmio: fix preserve mask for instructions with zero-extend
movzx is a move with zero-extend. It will either move 1 byte (0f b6) or
2 bytes (0f b7). The destination are lower 8 or 16 bits. Zero-extend
means that upper bits need to be cleared. The definition of upper bits
depends on the destination register.
We already have a preserve mask that allows us for to clear or preserve
bits when emulating the instruction. In case of movzx, the preserve mask
only depends on the width of the destination register. For the
destination register, we have the following cases:
- rax -- instruction has REX prefix 0x48 (rex_w set)
- eax -- default case, no prefix, nothing
- ax -- instruction has OP SZ override prefix 0x66
- al -- not possible, and doesn't make sense for movzx
Now, rax and eax have the same effect: Always clear all upper bits (IOW,
bits 8-63 if access_size is 1 or bits 16-63 if access_size is 2).
Solution for rax and eax is easy: Simply don't set the preserve mask at
all.
The fun part is if we have the 0x66 operand override size prefix. This
means that the 'visibility' of the destination register is narrowed to
16 bit.
In case of a 1 byte move (0f b6), copy the source to bits 0-7, clear
bits 8-15 and preserve bits 16-63. access_width ensures that we only
copy 8 bit to bits 0-7, and the preserve_mask 0xffff.ffff.ffff.0000 does
the rest: preserve bits 16-63 and implicitely clear bits 8-15.
In case of a 2 byte move (0f b7), copy the source to bits 0-15, clear
nothing and preserve bits 16-63. access_width ensures that we only copy
16 bit to bits 0-15, and the preserve_mask 0xffff.ffff.ffff.0000 does
the rest: preserve bits 16-63.
Once this pattern is clear, the fix in the hypervisor is straight forward.
Amend existing and add new test cases that test correct behaviour.
Signed-off-by: Ralf Ramsauer <[email protected]>
[Jan: minor comment and style massaging]
Signed-off-by: Jan Kiszka <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/siemens/jailhouse/push/refs/heads/next/73489e-23766c%40github.com.
For more options, visit https://groups.google.com/d/optout.
