Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752812AbbBMMCG (ORCPT ); Fri, 13 Feb 2015 07:02:06 -0500 Received: from mail.skyhub.de ([78.46.96.112]:35652 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752362AbbBMMCE (ORCPT ); Fri, 13 Feb 2015 07:02:04 -0500 Date: Fri, 13 Feb 2015 13:01:22 +0100 From: Borislav Petkov To: Denys Vlasenko Cc: Masami Hiramatsu , Ingo Molnar , Oleg Nesterov , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86: x86-opcode-map.txt: explain CALLW discrepancy between Intel and AMD Message-ID: <20150213120121.GC3712@pd.tnic> References: <1423768017-31766-1-git-send-email-dvlasenk@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1423768017-31766-1-git-send-email-dvlasenk@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1931 Lines: 59 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 > CC: Masami Hiramatsu > CC: Ingo Molnar > CC: Oleg Nesterov > 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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/