From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by sourceware.org (Postfix) with ESMTPS id 58F0E385800F for ; Fri, 26 Mar 2021 23:12:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 58F0E385800F Received: by mail.kernel.org (Postfix) with ESMTPSA id 1691D61A18 for ; Fri, 26 Mar 2021 23:12:38 +0000 (UTC) Received: by mail-ed1-f52.google.com with SMTP id h13so8061329eds.5 for ; Fri, 26 Mar 2021 16:12:37 -0700 (PDT) X-Gm-Message-State: AOAM530Kv2EscdHMCF5GMWH3r0weodY5A1sYJ+7TAPzc68+27sItQcjI 9VehxN0V4OggEQH+y+8OBH3nHw2He23Hod6wNMKckA== X-Google-Smtp-Source: ABdhPJyJHhr3Jeg/rskbL19tHEX1mN80b9QAR/1FBTRRwNpcItd4rIVGCIhhNN6fjGOUHstbVG8DnDdsj9GaEzSpMFY= X-Received: by 2002:a50:fa92:: with SMTP id w18mr17525282edr.172.1616800356579; Fri, 26 Mar 2021 16:12:36 -0700 (PDT) MIME-Version: 1.0 From: Andy Lutomirski Date: Fri, 26 Mar 2021 16:12:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Candidate Linux ABI for Intel AMX and hypothetical new related features To: "Bae, Chang Seok" , Dave Hansen , X86 ML , LKML , linux-abi@vger.kernel.org, libc-alpha , Florian Weimer , Rich Felker , Kyle Huey , Keno Fischer Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_MANYTO, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Fri, 26 Mar 2021 23:12:41 -0000 Hi all- After some discussion on IRC, I have a proposal for a Linux ABI for using Intel AMX and other similar features. It works like this: First, we make XCR0 dynamic. This looks a lot like Keno's patch but with a different API, outlined below. Different tasks can have different XCR0 values. The default XCR0 for new tasks does not include big features like AMX. XMM and YMM are still there. The AVX2 states are debatable -- see below. To detect features and control XCR0, we add some new arch_prctls: arch_prctl(ARCH_GET_XCR0_SUPPORT, 0, ...); returns the set of XCR0 bits supported on the current kernel. arch_prctl(ARCH_GET_XCR0_LAZY_SUPPORT, 0, ...); returns 0. See below. arch_prctl(ARCH_SET_XCR0, xcr0, lazy_states, sigsave_states, sigclear_states, 0); Sets xcr0. All states are preallocated except that states in lazy_states may be unallocated in the kernel until used. (Not supported at all in v1. lazy_states & ~xcr0 != 0 is illegal.) States in sigsave_states are saved in the signal frame. States in sigclear_states are reset to the init state on signal delivery. States in sigsave_states are restored by sigreturn, and states not in sigsave_states are left alone by sigreturn. Optionally we do not support PKRU at all in XCR0 -- it doesn't make that much sense as an XSAVE feature, and I'm not convinced that trying to correctly context switch XINUSE[PKRU] is worthwhile. I doubt we get it right today. Optionally we come up with a new format for new features in the signal frame, since the current format is showing its age. Taking 8kB for a signal with AMX is one thing. Taking another 8kB for a nested signal if AMX is not in use is worse. Optionally we make AVX-512 also default off, which fixes what is arguably a serious ABI break with AVX-512: lots of programs, following POSIX (!), seem to think that they know much much space to allocate for sigaltstack(). AVX-512 is too big. Thoughts? --Andy