On Thu, Feb 12, 2015 at 08:06:57PM +0100, Denys Vlasenko wrote:
> In 64-bit mode, AMD and Intel CPUs treat 0x66 prefix before branch
> insns differently. For near branches, it affects decode too since
> immediate offset's width is different.
>
> Signed-off-by: Denys Vlasenko <[email protected]>
> CC: Masami Hiramatsu <[email protected]>
> CC: Ingo Molnar <[email protected]>
> CC: Oleg Nesterov <[email protected]>
> CC: [email protected]
> ---
> arch/x86/lib/x86-opcode-map.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/x86/lib/x86-opcode-map.txt b/arch/x86/lib/x86-opcode-map.txt
> index 1a2be7c..816488c 100644
> --- a/arch/x86/lib/x86-opcode-map.txt
> +++ b/arch/x86/lib/x86-opcode-map.txt
> @@ -273,6 +273,9 @@ dd: ESC
> de: ESC
> df: ESC
> # 0xe0 - 0xef
> +# Note: "forced64" is Intel CPU behavior: they ignore 0x66 prefix
> +# in 64-bit mode. AMD CPUs accept 0x66 prefix, it causes RIP truncation
> +# to 16 bits. In 32-bit mode, 0x66 is accepted by both Intel and AMD.
Well, according to the SDM, Intel truncates too, see the LOOP/LOOPcc
Operation section:
...
IF BranchCond = 1
THEN
IF OperandSize = 32
THEN EIP ← EIP + SignExtend(DEST);
ELSE IF OperandSize = 64
THEN RIP ← RIP + SignExtend(DEST);
FI;
ELSE IF OperandSize = 16
THEN EIP ← EIP AND 0000FFFFH; <---
and text talks about 0x67 but that's address size and it is used to size
the rCX register.
So something must be setting the OperandSize and text doesn't mention
anywhere about 0x66 being ignored.
Or have you been doing some empirical experiments? :-)
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
