From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: Dave Hansen <dave.hansen@intel.com>,
"Yao, Yuan" <yuan.yao@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "x86@kernel.org" <x86@kernel.org>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86/fpu: Remove dynamic features from xcomp_bv for init_fpstate
Date: Thu, 13 Oct 2022 20:53:54 -0700 [thread overview]
Message-ID: <084b98d1-1021-14fd-0d7b-3b85ffee3035@intel.com> (raw)
In-Reply-To: <dd5815fa-ec61-b7d1-c0b3-70cd0f33bbee@intel.com>
On 10/13/2022 10:44 AM, Dave Hansen wrote:
>
> A better comment for that would be:
>
> * Some user_xfeatures may not be present in the fpstate.
> * Remove those from 'mask' to zero those features in the
> * user buffer instead of retrieving them from fpstate.
Yes, indeed!
Also this xstate copy routine looks to need some updates.
If an xfeature is present in fpstate, and in init state, the value is
retrieved from init_fpstate via copy_feature(). But, it has no space for
dynamic states. Also, for extended states, the init state is known to be
zero.
Then, perhaps, init_fpstate is better not to be accessed in the
for_each_extended_xfeature loop; instead of using copy_feature(), the
feature can be zeroed like this:
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 13b83b11b3d8..0fdfd03938b6 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -1150,11 +1150,11 @@ void __copy_xstate_to_uabi_buf(struct membuf to,
struct fpstate *fpstate,
*/
pkru.pkru = pkru_val;
membuf_write(&to, &pkru, sizeof(pkru));
- } else {
- copy_feature(header.xfeatures & BIT_ULL(i), &to,
- __raw_xsave_addr(xsave, i),
- __raw_xsave_addr(xinit, i),
+ } else if (header.xfeatures & BIT_ULL(i)) {
+ membuf_write(&to, __raw_xsave_addr(xsave, i),
xstate_sizes[i]);
+ } else {
+ membuf_zero(&to, xstate_sizes[i]);
}
Thanks,
Chang
next prev parent reply other threads:[~2022-10-14 3:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-11 22:24 Dave Hansen
2022-10-11 22:47 ` Chang S. Bae
2022-10-13 1:33 ` Yao, Yuan
2022-10-13 1:47 ` Chang S. Bae
2022-10-13 3:35 ` Yao, Yuan
2022-10-13 16:23 ` Chang S. Bae
2022-10-13 17:21 ` Dave Hansen
2022-10-13 17:33 ` Chang S. Bae
2022-10-13 17:44 ` Dave Hansen
2022-10-14 3:53 ` Chang S. Bae [this message]
2022-10-14 4:10 ` Yao, Yuan
2022-10-14 4:26 ` Chang S. Bae
2022-10-14 4:03 ` Yao, Yuan
2022-10-13 18:04 ` Dave Hansen
2022-10-17 22:39 ` Chang S. Bae
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=084b98d1-1021-14fd-0d7b-3b85ffee3035@intel.com \
--to=chang.seok.bae@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yuan.yao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®