[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <758089a4-52d5-4649-8aee-89e60044918a@intel.com>
Date: Thu, 9 May 2024 11:41:23 -0700
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: Dave Hansen <dave.hansen@...el.com>, <linux-kernel@...r.kernel.org>
CC: <x86@...nel.org>, <platform-driver-x86@...r.kernel.org>,
<tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
<dave.hansen@...ux.intel.com>, <hdegoede@...hat.com>,
<ilpo.jarvinen@...ux.intel.com>, <tony.luck@...el.com>,
<ashok.raj@...el.com>, <jithu.joseph@...el.com>
Subject: Re: [PATCH v2 1/2] x86/fpu: Extend kernel_fpu_begin_mask() to
initialize AMX state
On 5/9/2024 10:36 AM, Dave Hansen wrote:
>
> I'd probably just do this:
>
> + kernel_fpu_begin();
> + // AMX *MUST* be in the init state for the wrmsr() to work.
> + // But, the more in the init state, the less state the test
> + // has to save and restore. Just zap everything.
> + restore_fpregs_from_fpstate(&init_fpstate,
> + fpu_user_cfg.max_features);
> +
I assume that this snippet goes to the IFS driver side. Then, we need to
introduce and export a new wrapper for this.
restore_fpregs_from_fpstate() and its arguments are not accessible as of
now.
Also, I think we should encapsulate them. If we follow this style, we
could have invoked tilerelease() directly from the idle driver, right?
> wrmsrl(MSR_ACTIVATE_SCAN, params->activate->data);
> rdmsrl(MSR_SCAN_STATUS, status.data);
>
> + kernel_fpu_end();
Powered by blists - more mailing lists