From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753457AbcHQT07 (ORCPT ); Wed, 17 Aug 2016 15:26:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43634 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752971AbcHQT06 (ORCPT ); Wed, 17 Aug 2016 15:26:58 -0400 Subject: Re: RFC: Petition Intel/AMD to add POPF_IF insn To: Andy Lutomirski , Linus Torvalds References: <8de26c33-5597-bf00-2ac5-d265ba01d0d4@redhat.com> Cc: Sara Sharon , Dan Williams , =?UTF-8?Q?Christian_K=c3=b6nig?= , Vinod Koul , Alex Deucher , Johannes Berg , "Rafael J. Wysocki" , Andy Lutomirski , the arch/x86 maintainers , Ingo Molnar , LKML , Adrian Hunter From: Denys Vlasenko Message-ID: Date: Wed, 17 Aug 2016 21:26:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 17 Aug 2016 19:26:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/17/2016 09:13 PM, Andy Lutomirski wrote: > On Wed, Aug 17, 2016 at 12:01 PM, Linus Torvalds > wrote: >> On Aug 17, 2016 11:41 AM, "Denys Vlasenko" wrote: >>> >>> OTOH 5 years will inevitably pass. >> >> Yes. But in five years, maybe we'll have a popf that is faster anyway. >> >> I'd actually prefer that in the end. The problem with popf right now seems >> to be mainly that it's effectively serializing and does stupid things in >> microcode. It doesn't have to be that way. It could actually do much better, >> but it hasn't been a high enough priority for Intel. >> > > It wouldn't surprise me if that were easier said than done. popf > potentially changes AC, and AC affects address translation. popf also > potentially changes IOPL, and I don't know whether Intel chips track > IOPL in a way that lets them find all the dependent instructions > without serializing. But maybe their pipeline is fancy enough. Exactly. And more: POPF potentially changes TF (and it works even in CPL3). POPD changes DF - must serialize versus string insns. POPF changes NT - must serialize versus IRET insns. POPF changes VIF, from a different bit in a popped value, and under a rather complex conditions. Intel's documentation has a pseudo-code for the instructions. For POPF, that pseudo-code is two pages long...