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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 3A969C433E0 for ; Mon, 29 Mar 2021 16:49:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 069CF61920 for ; Mon, 29 Mar 2021 16:49:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231173AbhC2Qsf (ORCPT ); Mon, 29 Mar 2021 12:48:35 -0400 Received: from albireo.enyo.de ([37.24.231.21]:45770 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229630AbhC2QsR (ORCPT ); Mon, 29 Mar 2021 12:48:17 -0400 Received: from [172.17.203.2] (port=58345 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lQv3d-0006Ik-Dr; Mon, 29 Mar 2021 16:48:05 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1lQv3d-000688-9F; Mon, 29 Mar 2021 18:48:05 +0200 From: Florian Weimer To: Len Brown via Libc-alpha Cc: Greg KH , Len Brown , Rich Felker , Linux API , "Bae\, Chang Seok" , X86 ML , LKML , Dave Hansen , Kyle Huey , Andy Lutomirski , Keno Fischer Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features References: Date: Mon, 29 Mar 2021 18:48:05 +0200 In-Reply-To: (Len Brown via Libc-alpha's message of "Mon, 29 Mar 2021 12:38:59 -0400") Message-ID: <87eefxucsa.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Len Brown via Libc-alpha: >> In particular, the library may use instructions that main() doesn't know exist. > > And so I'll ask my question another way. > > How is it okay to change the value of XCR0 during the run time of a > program? > > I submit that it is not, and that is a deal-killer for a > request/release API. > > eg. main() doesn't know that the math library wants to use AMX, and > neither does the threading library. So main() doesn't know to call > the API before either library is invoked. The threading library > starts up and creates user-space threads based on the initial value > from XCR0. Then the math library calls the API, which adds bits to > XCRO, and then the user-space context switch in the threading > library corrupts data because the new XCR0 size doesn't match the > initial size. I agree that this doesn't quite work. (Today, it's not the thread library, but the glibc dynamic loader trampoline.) I disagree that CPU feature enablement has been a failure. I think we are pretty good at enabling new CPU features on older operating systems, not just bleeding edge mainline kernels. Part of that is that anything but the kernel stays out of the way, and most features are available directly via inline assembly (you can even use .byte hacks if you want). There is no need to switch to new userspace libraries, compile out-of-tree kernel drivers that have specific firmware requirements, and so on. If the operations that need a huge context can be made idempotent, with periodic checkpoints, it might be possible to avoid saving the context completely by some rseq-like construct.