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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 C1F08C433B4 for ; Wed, 31 Mar 2021 22:46:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 94AB36105A for ; Wed, 31 Mar 2021 22:46:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232596AbhCaWps (ORCPT ); Wed, 31 Mar 2021 18:45:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:39188 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232600AbhCaWpW (ORCPT ); Wed, 31 Mar 2021 18:45:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id DB70061090 for ; Wed, 31 Mar 2021 22:45:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617230722; bh=3Npb6Zu3DJw/HynXi+oVJZahQt437+yrIYrwcSK5DQE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=u1Uyl5p7jTOPv+XhIr1pdo0/HK1e9UwrBM813xOUbU/1YdwzokWEry22ijhoGpr2U GAb1PNvB/u0UGGluAYcoDGshCyqU4W6vkkrWIagMbfENEe/zwzP0UNuJSc7MWcbJCO J36YHtWXUdlx7jJFi1+yCGQcdVYCA4OkZACwrYYmcAH+H4Qi2JvkUhceUVlTt0s7id dG6lEyLqZIEmV+QrG7B5JdmXBOKzGmLMRQx10mlGu0hVOYoNuTuHInDmQxo8FKPcMa U+UrpPBTr8n/bc2eMsiO13VPdyc7ROub+92IFBc3QMJbr7Vd3clFGIh8ZzhaU7r82k D73DQ9tyZirwg== Received: by mail-ej1-f51.google.com with SMTP id ap14so66595ejc.0 for ; Wed, 31 Mar 2021 15:45:21 -0700 (PDT) X-Gm-Message-State: AOAM533yQTBhpEvH4zmYaMQZ5bubQrzi+AAdT/QEXxgarU7PSkdtBH4E PyP+pYmb0iaip0WkUspX+R+o9XOr980CU/UD18+v2Q== X-Google-Smtp-Source: ABdhPJyVEN9n4F0AQVaeVGiDBkMPxzCjBvJV7GTSw60MJR4FYm48tMLigo5/888YsdcsY6EAC+rkDHTd3MMn/9/PUsk= X-Received: by 2002:a17:907:e88:: with SMTP id ho8mr6255028ejc.199.1617230720393; Wed, 31 Mar 2021 15:45:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Lutomirski Date: Wed, 31 Mar 2021 15:45:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features To: Len Brown 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: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Wed, Mar 31, 2021 at 3:28 PM Len Brown wrote: > > On Wed, Mar 31, 2021 at 12:53 PM Andy Lutomirski wr= ote: > > > 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. I followed your link and found nothing. Can you elaborate? In the kernel, we have noinstr, and gcc gives approximately no help toward catching problems. > > Why would compiler support for fast-signals be any more "serious"? > > > An API like: > > > > if (get_amx()) { > > use AMX; > > } else { > > don=E2=80=99t; > > } > > > > Avoids this problem. And making XCR0 dynamic, for all its faults, at le= ast helps force a degree of discipline on user code. > > dynamic XCR0 breaks the installed base, I thought we had established that= . I don't think this is at all established. If some code thinks it knows the uncompacted XSTATE size and XCR0 changes, it crashes. This is not necessarily a showstopper. > > We've also established that when running in a VMM, every update to > XCR0 causes a VMEXIT. This is true, it sucks, and Intel could fix it going forward. > > 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. That is *a* goal, but not necessarily the only goal. --Andy