Re: [PATCH] x86: x86-opcode-map.txt: explain CALLW discrepancy between Intel and AMD

[Borislav Petkov <bp@alien8.de>]

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 <dvlasenk@redhat.com>
> CC: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> CC: Ingo Molnar <mingo@kernel.org>
> CC: Oleg Nesterov <oleg@redhat.com>
> CC: linux-kernel@vger.kernel.org
> ---
>  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.
--