From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225MZ5pGElfj7gZE6gHwEUHpZlOmvdDn1h5AfKA7xVyObET7iR7DVpMdukeQyYuUIGYFIypJ ARC-Seal: i=1; a=rsa-sha256; t=1516718364; cv=none; d=google.com; s=arc-20160816; b=cgFUDxalVBck5uVlmSQvYRiynApXUflLSiq95BmCiSxTaOlLIrisFOLxWN/oAqiWPB gHQhnK8NLWN3N25FnWkJ4KHn10mYVpFWUNpjtBf/a60YwqmEDyG198QTGPy8AspatVk6 pyBVhtBZ5pYFC8fYQBROi/RX1sQfRhdOkBJGwV4i5/ix6RuVRveOEvDcmMWLLyWuKU5T 5gx2YePlac19P/SaKqG8cGtqk4E6BWvyQLe3Okcq9W4xjvjZYEhJrtR3Ka3QlDLYulvT PtpoBazhoyTO4axK1UGDmpndDnWcWK2eo58L5zOeFpN1rrBxurEt3n7Ww8j9xzdhh8dH N8lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=BaQ4YMQijeeGMHlpXWq0m/olIH6slPO9tKqeB+Nme7s=; b=fXbkEU+1d8TtoccqPR5OP8JhbFe8uiVzTVTCmXaY3YPi3KdkOpPoaCQklXKF9zY3NH jMyr+/bBdh6CAtM2FWv48Fd7Zr/pxsx+sPLhcfnd0cql0DHhxK7AypmgKpqOjD1+g5fG hecAqK6mVsa3VVfGZU1LAOPnRF6IR5elL08xwxcYGxRGIL2G9Q2m5NaLXULpkYMfLG4P Hro/pHDRFJevpZQI0Gk/KrT3bw9U2JuaKoFvsK2lNfw/IrmOJ6caoIU0twyVV3ii13bB wRLbboq9eqjQ47qPHtw3+Y2Q6ox4iwHthICvC5mJk4n/7WZ86PkjtSMrE+9uNZy87r57 zT/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of gnomes@lxorguk.ukuu.org.uk designates 82.70.14.225 as permitted sender) smtp.mailfrom=gnomes@lxorguk.ukuu.org.uk Authentication-Results: mx.google.com; spf=pass (google.com: domain of gnomes@lxorguk.ukuu.org.uk designates 82.70.14.225 as permitted sender) smtp.mailfrom=gnomes@lxorguk.ukuu.org.uk Date: Tue, 23 Jan 2018 14:38:31 +0000 From: Alan Cox To: "H. Peter Anvin" Cc: Linus Torvalds , Nadav Amit , Joerg Roedel , Thomas Gleixner , Ingo Molnar , the arch/x86 maintainers , LKML , "open list:MEMORY MANAGEMENT" , Andy Lutomirski , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Greg KH , Will Deacon , "Liguori, Anthony" , Daniel Gruss , Hugh Dickins , Kees Cook , Andrea Arcangeli , Waiman Long , Joerg Roedel Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 Message-ID: <20180123143831.2d769f9d@alans-desktop> In-Reply-To: References: <1516120619-1159-1-git-send-email-joro@8bytes.org> <5D89F55C-902A-4464-A64E-7157FF55FAD0@gmail.com> <886C924D-668F-4007-98CA-555DB6279E4F@gmail.com> <9CF1DD34-7C66-4F11-856D-B5E896988E16@gmail.com> <143DE376-A8A4-4A91-B4FF-E258D578242D@zytor.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589767841591470697?= X-GMAIL-MSGID: =?utf-8?q?1590394475775720007?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: > of timing requirements vs complexity. At least theoretically one could > imagine a machine which would take the trap after the speculative > machine had already chased the pointer loop several levels down; this > would most likely mean separate uops to allow for the existing > out-of-order machine to do the bookkeeping. It's not quite the same but in the IA-64 case you can write itanium code that does exactly that. The speculation is expressed in software not hardware (because you can trigger a load, then check later if it worked out and respond appripriately). Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id DA8CE800D8 for ; Tue, 23 Jan 2018 09:39:23 -0500 (EST) Received: by mail-wm0-f72.google.com with SMTP id z83so514997wmc.5 for ; Tue, 23 Jan 2018 06:39:23 -0800 (PST) Received: from fuzix.org (www.llwyncelyn.cymru. [82.70.14.225]) by mx.google.com with ESMTPS id u6si374331wrb.183.2018.01.23.06.39.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jan 2018 06:39:22 -0800 (PST) Date: Tue, 23 Jan 2018 14:38:31 +0000 From: Alan Cox Subject: Re: [RFC PATCH 00/16] PTI support for x86-32 Message-ID: <20180123143831.2d769f9d@alans-desktop> In-Reply-To: References: <1516120619-1159-1-git-send-email-joro@8bytes.org> <5D89F55C-902A-4464-A64E-7157FF55FAD0@gmail.com> <886C924D-668F-4007-98CA-555DB6279E4F@gmail.com> <9CF1DD34-7C66-4F11-856D-B5E896988E16@gmail.com> <143DE376-A8A4-4A91-B4FF-E258D578242D@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "H. Peter Anvin" Cc: Linus Torvalds , Nadav Amit , Joerg Roedel , Thomas Gleixner , Ingo Molnar , the arch/x86 maintainers , LKML , "open list:MEMORY MANAGEMENT" , Andy Lutomirski , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Greg KH , Will Deacon , "Liguori, Anthony" , Daniel Gruss , Hugh Dickins , Kees Cook , Andrea Arcangeli , Waiman Long , Joerg Roedel > of timing requirements vs complexity. At least theoretically one could > imagine a machine which would take the trap after the speculative > machine had already chased the pointer loop several levels down; this > would most likely mean separate uops to allow for the existing > out-of-order machine to do the bookkeeping. It's not quite the same but in the IA-64 case you can write itanium code that does exactly that. The speculation is expressed in software not hardware (because you can trigger a load, then check later if it worked out and respond appripriately). Alan -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org