From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by sourceware.org (Postfix) with ESMTPS id E19633857420 for ; Thu, 20 May 2021 19:16:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E19633857420 Received: by mail-ed1-f44.google.com with SMTP id i13so20664704edb.9 for ; Thu, 20 May 2021 12:16:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HqMs01SwhIzac61wHIqbpImRVDJ7bAhjZqygW+SGW5k=; b=KgUorcpgSEUvzlsK8WxM8WDDmagEWNF7T85hjpzgfHgozEFGujr0rJ2fxMslLsu3Ry jwPuGMWqOrptDtMuK8xQxZ3/Vzgs91Oc6ra2ja+UsNtIRbxAtfgb92XRQQKuzvT/R6/k sJCToK8SZLSTSAIT/BMqz7kxn/DYGeO1AZ6v2cvkVGLxXIjHE+2S2XlB02qyGNpMmW8u +ZhadOLBqoV5ITETaYsQaOpVaV0lKybJr9n8eiBnJZA7g2ZK3F9Zn72mTy+fNKGPOm2m 0srOgyhZxhxLq1MAd5MKG4Ke2lioZG412QHSPNZ57vh3aCDIgrZXgaR1wULVmGKTSc56 spmA== X-Gm-Message-State: AOAM530mF16g6IM0ugnSTAdxBCrxYP6B1ADq+892qw6m2l9Pj668dslJ P0D8laskkUaL2izG6ggbrsDNJxISQhtKGaScgXQ= X-Google-Smtp-Source: ABdhPJyh43njdKBMqfGDgRouJG4tcrfxgxr8+9fee8ftTi2kkTl4QjUJ4jlGUE7IFuDfm/ed932lAGPXA1M5uOR40M4= X-Received: by 2002:a05:6402:2789:: with SMTP id b9mr6665889ede.122.1621538188915; Thu, 20 May 2021 12:16:28 -0700 (PDT) MIME-Version: 1.0 References: <20210415044258.GA6318@zn.tnic> <20210415052938.GA2325@1wt.eu> <20210415054713.GB6318@zn.tnic> <20210419141454.GE9093@zn.tnic> <20210419191539.GH9093@zn.tnic> <20210419215809.GJ9093@zn.tnic> <8735uxmucw.ffs@nanos.tec.linutronix.de> In-Reply-To: From: Len Brown Date: Thu, 20 May 2021 15:16:17 -0400 Message-ID: Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features To: Andy Lutomirski Cc: Thomas Gleixner , Borislav Petkov , Willy Tarreau , Florian Weimer , "Bae, Chang Seok" , Dave Hansen , X86 ML , LKML , linux-abi@vger.kernel.org, "libc-alpha@sourceware.org" , Rich Felker , Kyle Huey , Keno Fischer Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 19:16:31 -0000 On Wed, May 19, 2021 at 7:29 PM Andy Lutomirski wrote: > > It is established that there exists application code that counts on > > this opaque state being complete so that it can do a user-space > > XRESTORE instead of a sigreturn(2). > > Is this established? > > Note that the specific case of a user program doing XRSTOR will work > just fine if we omit the allocation of non-in-use states from the > buffer, at least by my reading of the pseudocode. Yes, your understanding is correct -- XRESTOR works as one would expect. > The case that would > break is if user code then assumes that it can XSAVE back to the same > buffer. The other case that would break is if the concept of what features were supported (eg. XCR0) changed between when the context was saved and when it was subsequently restored. Yes, if a feature appeared, you'd get INIT; but if a feature went away, you would fault. I've been told that user-space software exists that does this. If I can find specific examples, I'll share that. thanks, Len Brown, Intel Open Source Technology Center