From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4DE4EC43460 for ; Wed, 31 Mar 2021 22:29:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0FC2161077 for ; Wed, 31 Mar 2021 22:29:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229968AbhCaW2x convert rfc822-to-8bit (ORCPT ); Wed, 31 Mar 2021 18:28:53 -0400 Received: from mail-ed1-f51.google.com ([209.85.208.51]:37676 "EHLO mail-ed1-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232690AbhCaW2j (ORCPT ); Wed, 31 Mar 2021 18:28:39 -0400 Received: by mail-ed1-f51.google.com with SMTP id x21so24086316eds.4; Wed, 31 Mar 2021 15:28:39 -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:content-transfer-encoding; bh=qO/MnGOAo2aKNNZIMFKn7K57e/u6m6J452MXAoHJnn0=; b=VxVbnybetLd06dvzjpOW7fRjTvptvQ0C9ydDaWd+Tj7B6saGjfrdIOPAL9/cUfjT5q o43IS5hAL25S7NS0tQiBZQcjlJScLBn435uQKeauFeCiH6kmTfOS2kFj1P3c08mrRtvW FMR9yfTsp9fdvEuWh0i1jfVK3CJXkPqReU5w2sJ168yg9xN+PSACNqeMZl/23JtOtRMy VONuR4SjF+wpHNyIl9GOk+9GSY5yydc4txbOF43bbnqcwnfIizBXyYq4etC40Thcx511 nJ12sjzTWOWMJ9p8cyrtts2xpCxhspdDJpBqhdx35CCjxDKOvSKyjej1ZjVx+QucSWu4 iPjg== X-Gm-Message-State: AOAM530u+z8xAahD2aaL/+bdJK+vwr7rs/MLqUeD6muOaQxINCP8BKOi kWkZQz/F2VZeeChIDZ5Mj0NZ3HjZZgc98F6rZV0= X-Google-Smtp-Source: ABdhPJyCavZ4RcFBgd4wNh9CfsMfm1DD0nwSyeJZ5JeXCQN+/vQREPStBukJfuirUEvE5rOX7izGJkTaySudPgwlUhA= X-Received: by 2002:aa7:d917:: with SMTP id a23mr6502007edr.122.1617229718626; Wed, 31 Mar 2021 15:28:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Len Brown Date: Wed, 31 Mar 2021 18:28:27 -0400 Message-ID: Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features To: Andy Lutomirski Cc: David Laight , Dave Hansen , Andy Lutomirski , Greg KH , "Bae, Chang Seok" , X86 ML , LKML , libc-alpha , Florian Weimer , Rich Felker , Kyle Huey , Keno Fischer , Linux API Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 31, 2021 at 12:53 PM Andy Lutomirski wrote: > But this whole annotation thing will require serious compiler support. > We already have problems with compilers inlining functions and getting confused about attributes. We added compiler annotation for user-level interrupt handlers. I'm not aware of it failing, or otherwise being confused. Why would compiler support for fast-signals be any more "serious"? > An API like: > > if (get_amx()) { > use AMX; > } else { > don’t; > } > > Avoids this problem. And making XCR0 dynamic, for all its faults, at least helps force a degree of discipline on user code. dynamic XCR0 breaks the installed base, I thought we had established that. We've also established that when running in a VMM, every update to XCR0 causes a VMEXIT. I thought the goal was to allow new programs to have fast signal handlers. By default, those fast signal handlers would have a stable state image, and would not inherit large architectural state on their stacks, and could thus have minimal overhead on all hardware.