From: Dave Hansen <dave.hansen@intel.com>
To: "Chang S. Bae" <chang.seok.bae@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 10:21:28 -0700 [thread overview]
Message-ID: <78f2021e-339f-9dfb-2aee-51f58ea77ec9@intel.com> (raw)
In-Reply-To: <9b198ed3-4b2d-c857-710b-3f7115bbcf74@intel.com>
On 10/13/22 09:23, Chang S. Bae wrote:
>
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -1127,8 +1127,12 @@ void __copy_xstate_to_uabi_buf(struct membuf to,
> struct fpstate *fpstate,
> * non-compacted format disabled features still occupy state space,
> * but there is no state to copy from in the compacted
> * init_fpstate. The gap tracking will zero these states.
> + *
> + * In the case of guest fpstate, this user_xfeatures does not
> + * dynamically reflect the capacity of the XSAVE buffer but
> + * xfeatures does. So AND them together.
> */
> - mask = fpstate->user_xfeatures;
> + mask = fpstate->user_xfeatures & fpstate->xfeatures;
I'm not sure this is quite right either.
Doesn't kvm expect that all of the ->user_xfeatures will end up being
copied out? We surely can't copy them from 'fpstate' if the feature
isn't there, but we can't skip them entirely, can we?
next prev parent reply other threads:[~2022-10-13 17:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-11 22:24 [PATCH] x86/fpu: Remove dynamic features from xcomp_bv for init_fpstate 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 [this message]
2022-10-13 17:33 ` Chang S. Bae
2022-10-13 17:44 ` Dave Hansen
2022-10-14 3:53 ` Chang S. Bae
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=78f2021e-339f-9dfb-2aee-51f58ea77ec9@intel.com \
--to=dave.hansen@intel.com \
--cc=chang.seok.bae@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