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,URIBL_BLOCKED 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 A4755C43460 for ; Fri, 9 Apr 2021 21:44:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 78F4661182 for ; Fri, 9 Apr 2021 21:44:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234811AbhDIVos (ORCPT ); Fri, 9 Apr 2021 17:44:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:40518 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234513AbhDIVor (ORCPT ); Fri, 9 Apr 2021 17:44:47 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7DF4C61184 for ; Fri, 9 Apr 2021 21:44:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618004673; bh=a/kaeUNYcF7//ieh1oEiBXj+7BcjAHHvsNrMfouzdE8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gGDF6qDj9ZJHa9yBOkUCJ6974hheYKKbt3iUUFcq1AsOyPzmTc8H5nyB4HCaPaMJ/ yvWJzb3WbVEkME0X8tB9hRl3MJVfIBpkWCIGSroVxgYz9ZoSWzhqIEPEseRsDEN2xw jsbuM4TPGz+LuDUHwA0HdWQhjDbohdpRZ2wwLE3ZbxI7JbojOlYou9X9ILxxpCl8vk jF6yFFUlC5dSr70E+pwM5acAFAgRh9xcLB9g9OJVRov1LnTPKX07zJQhZf23AEFa8v xtAKx76fjAXvuI2ADjd6xuCjArcHdmxgEe31Do4CURbKitgHDSG3+UhtXk6NBYbDte g3/6kO9ROgZZQ== Received: by mail-ed1-f54.google.com with SMTP id s15so8164457edd.4 for ; Fri, 09 Apr 2021 14:44:33 -0700 (PDT) X-Gm-Message-State: AOAM530wgenT/OPEriQeSAlVW2CgxqJdTyPj4g6oAOthEb1t2wryLUU1 Iw4ObpreXphJl4r8hiMlcNCobLXUUNDvrrOCNNF8bQ== X-Google-Smtp-Source: ABdhPJz6NU2aDEU9x5zPavuQ8sQx+9aDxNPWx+FWEIMpOS/YBBpEmDZIIGjBEjb7+oPf7OwX9apqM1I0ObUbiBvRBS8= X-Received: by 2002:aa7:c144:: with SMTP id r4mr4310485edp.222.1618004672078; Fri, 09 Apr 2021 14:44:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Lutomirski Date: Fri, 9 Apr 2021 14:44:20 -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: Andy Lutomirski , David Laight , Dave Hansen , 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 9, 2021 at 1:53 PM Len Brown wrote: > > On Wed, Mar 31, 2021 at 6:45 PM Andy Lutomirski wrote: > > > > On Wed, Mar 31, 2021 at 3:28 PM Len Brown wrote: > > > > > 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. > > A search for the word "interrupt" on this page > https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes > comes to the description of this attribute: > > __attribute__ ((interrupt)) > I read that and I see no mention of anything saying "this will generate code that does not touch extended state". Instead I see, paraphrasing, "this will generate code with an ABI that is completely inappropriate for use in a user space signal handler". Am I missing something? > > > 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. > > My working assumption is that crashing applications actually *is* a showstopper. > Please clarify. I think you're presuming that some program actually does this. If no program does this, it's not an ABI break. More relevantly, this can only happen in a process that uses XSAVE and thinks it knows the size that *also* does the prctl to change XCR0. By construction, existing programs can't break unless they load new dynamic libraries that break them. > > > > 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. > > What hardware fix do you suggest? > If a guest is permitted to set XCR0 bits without notifying the VMM, > what happens when it sets bits that the VMM doesn't know about? The VM could have a mask of allowed XCR0 bits that don't exist. TDX solved this problem *somehow* -- XSETBV doesn't (visibly?) exit on TDX. Surely plain VMX could fix it too. > > > > 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. > > I fully support coming up with a scheme for fast future-proof signal handlers, > and I'm willing to back that up by putting work into it. > > I don't see any other goals articulated in this thread. Before we get too carried away with *fast* signal handlers, something that works with existing programs is also a pretty strong goal. RIght now AVX-512 breaks existing programs, even if they don't use AVX-512.