From: Dave Hansen <dave.hansen@intel.com>
To: Chao Gao <chao.gao@intel.com>,
tglx@linutronix.de, x86@kernel.org, seanjc@google.com,
pbonzini@redhat.com, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Cc: peterz@infradead.org, rick.p.edgecombe@intel.com,
mlevitsk@redhat.com, weijiang.yang@intel.com, john.allen@amd.com
Subject: Re: [PATCH v2 5/6] x86/fpu/xstate: Create guest fpstate with guest specific config
Date: Tue, 4 Mar 2025 15:02:04 -0800 [thread overview]
Message-ID: <d6127d2e-ea95-4e52-b3db-b39203bad935@intel.com> (raw)
In-Reply-To: <20241126101710.62492-6-chao.gao@intel.com>
On 11/26/24 02:17, Chao Gao wrote:
> From: Yang Weijiang <weijiang.yang@intel.com>
>
> Use fpu_guest_cfg to calculate guest fpstate settings, open code for
> __fpstate_reset() to avoid using kernel FPU config.
>
> Below configuration steps are currently enforced to get guest fpstate:
> 1) Kernel sets up guest FPU settings in fpu__init_system_xstate().
> 2) User space sets vCPU thread group xstate permits via arch_prctl().
> 3) User space creates guest fpstate via __fpu_alloc_init_guest_fpstate()
> for vcpu thread.
> 4) User space enables guest dynamic xfeatures and re-allocate guest
> fpstate.
>
> By adding kernel dynamic xfeatures in above #1 and #2, guest xstate area
> size is expanded to hold (fpu_kernel_cfg.default_features | kernel dynamic
> xfeatures | user dynamic xfeatures), then host xsaves/xrstors can operate
> for all guest xfeatures.
These changelogs have a lot of content, but they're honestly not helping
my along here very much.
> arch/x86/kernel/fpu/core.c | 39 +++++++++++++++++++++++++++++---------
> 1 file changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
> index 9e2e5c46cf28..00d7dcf45b34 100644
> --- a/arch/x86/kernel/fpu/core.c
> +++ b/arch/x86/kernel/fpu/core.c
> @@ -194,8 +194,6 @@ void fpu_reset_from_exception_fixup(void)
> }
>
> #if IS_ENABLED(CONFIG_KVM)
> -static void __fpstate_reset(struct fpstate *fpstate, u64 xfd);
> -
> static void fpu_init_guest_permissions(struct fpu_guest *gfpu)
> {
> struct fpu_state_perm *fpuperm;
> @@ -216,25 +214,48 @@ static void fpu_init_guest_permissions(struct fpu_guest *gfpu)
> gfpu->perm = perm & ~FPU_GUEST_PERM_LOCKED;
> }
>
> -bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu)
> +static struct fpstate *__fpu_alloc_init_guest_fpstate(struct fpu_guest *gfpu)
> {
> struct fpstate *fpstate;
> unsigned int size;
>
> - size = fpu_user_cfg.default_size + ALIGN(offsetof(struct fpstate, regs), 64);
> + /*
> + * fpu_guest_cfg.default_size is initialized to hold all enabled
> + * xfeatures except the user dynamic xfeatures. If the user dynamic
> + * xfeatures are enabled, the guest fpstate will be re-allocated to
> + * hold all guest enabled xfeatures, so omit user dynamic xfeatures
> + * here.
> + */
> + size = fpu_guest_cfg.default_size + ALIGN(offsetof(struct fpstate, regs), 64);
> +
> fpstate = vzalloc(size);
> if (!fpstate)
> - return false;
> + return NULL;
> + /*
> + * Initialize sizes and feature masks, use fpu_user_cfg.*
> + * for user_* settings for compatibility of exiting uAPIs.
> + */
> + fpstate->size = fpu_guest_cfg.default_size;
> + fpstate->xfeatures = fpu_guest_cfg.default_features;
> + fpstate->user_size = fpu_user_cfg.default_size;
> + fpstate->user_xfeatures = fpu_user_cfg.default_features;
> + fpstate->xfd = 0;
>
> - /* Leave xfd to 0 (the reset value defined by spec) */
> - __fpstate_reset(fpstate, 0);
> fpstate_init_user(fpstate);
> fpstate->is_valloc = true;
> fpstate->is_guest = true;
>
> gfpu->fpstate = fpstate;
> - gfpu->xfeatures = fpu_user_cfg.default_features;
> - gfpu->perm = fpu_user_cfg.default_features;
> + gfpu->xfeatures = fpu_guest_cfg.default_features;
> + gfpu->perm = fpu_guest_cfg.default_features;
> +
> + return fpstate;
> +}
> +
> +bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu)
> +{
> + if (!__fpu_alloc_init_guest_fpstate(gfpu))
> + return false;
>
> /*
> * KVM sets the FP+SSE bits in the XSAVE header when copying FPU state
This series is starting to look backward to me.
The normal way you do these things is that you introduce new
abstractions and refactor the code. Then you go adding features.
For instance, this series should spend a few patches introducing
'fpu_guest_cfg' and using it before ever introducing the concept of a
dynamic xfeature.
next prev parent reply other threads:[~2025-03-04 23:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-26 10:17 [PATCH v2 0/6] Introduce CET supervisor state support Chao Gao
2024-11-26 10:17 ` [PATCH v2 1/6] x86/fpu/xstate: Always preserve non-user xfeatures/flags in __state_perm Chao Gao
2025-03-04 22:20 ` Dave Hansen
2025-03-05 8:25 ` Chao Gao
2024-11-26 10:17 ` [PATCH v2 2/6] x86/fpu/xstate: Add CET supervisor mode state support Chao Gao
2025-03-04 22:26 ` Dave Hansen
2025-03-05 8:32 ` Chao Gao
2024-11-26 10:17 ` [PATCH v2 3/6] x86/fpu/xstate: Introduce XFEATURE_MASK_KERNEL_DYNAMIC xfeature set Chao Gao
2025-03-04 22:37 ` Dave Hansen
2025-03-05 8:43 ` Chao Gao
2024-11-26 10:17 ` [PATCH v2 4/6] x86/fpu/xstate: Introduce fpu_guest_cfg for guest FPU configuration Chao Gao
2025-03-04 22:50 ` Dave Hansen
2025-03-05 8:57 ` Chao Gao
2024-11-26 10:17 ` [PATCH v2 5/6] x86/fpu/xstate: Create guest fpstate with guest specific config Chao Gao
2025-03-04 23:02 ` Dave Hansen [this message]
2025-03-05 9:04 ` Chao Gao
2024-11-26 10:17 ` [PATCH v2 6/6] x86/fpu/xstate: Warn if CET supervisor state is detected in normal fpstate Chao Gao
2024-11-26 10:28 ` [PATCH v2 0/6] Introduce CET supervisor state support Chao Gao
2025-01-11 1:26 ` Sean Christopherson
2025-02-11 2:09 ` Xin Li
2025-03-04 19:40 ` Xin Li
2025-03-04 19:53 ` Sean Christopherson
2025-02-19 1:44 ` Chao Gao
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=d6127d2e-ea95-4e52-b3db-b39203bad935@intel.com \
--to=dave.hansen@intel.com \
--cc=chao.gao@intel.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=weijiang.yang@intel.com \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.