[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvTdKng_WMrmO_KtkuCxvvzGZ_HLcd84u2SwJiD_UJivb4Yaw@mail.gmail.com>
Date: Tue, 24 Nov 2020 13:50:58 -0500
From: Len Brown <lenb@...nel.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: "Chang S. Bae" <chang.seok.bae@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
X86 ML <x86@...nel.org>, Len Brown <len.brown@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
"Liu, Jing2" <jing2.liu@...el.com>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v2 22/22] x86/fpu/xstate: Introduce boot-parameters for
control some state component support
On Fri, Nov 20, 2020 at 12:03 AM Andy Lutomirski <luto@...nel.org> wrote:
>
> On Thu, Nov 19, 2020 at 3:37 PM Chang S. Bae <chang.seok.bae@...el.com> wrote:
> > "xstate.enable=0x60000" will enable AMX on a system that does NOT have AMX
> > compiled into XFEATURE_MASK_USER_ENABLED (assuming the kernel is new enough
> > to support this feature).
> >
>
> What's the purpose of xstate.enable? I can't really imagine it's
> useful for AMX. I suppose it could be useful for hypothetical
> post-AMX features, but that sounds extremely dangerous. Intel has
> changed its strategy so many times on XSTATE extensibility that I find
> it quite hard to believe that supporting unknown states is wise.
Not hypothetical -- there are subsequent hardware features coming that
will use the same
exact XSTATE support that this series puts in place for AMX.
We know that when those features ship in new hardware, there will be
a set of customers who want to exercise those features immediately,
but their kernel binary has not yet been re-compiled to see those
features by-default.
The purpose of "xstate.enable" is to empower those users to be able to
explicitly enable support using their existing binary.
You are right -- the feature isn't needed to enable AMX, unless somebody went to
the trouble of building a kernel with the AMX source update, but chose
to disable
AMX-specific recognition, by-default.
thanks,
Len Brown, Intel Open Source Technology Center
Powered by blists - more mailing lists