From: Chao Gao <chao.gao@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: <tglx@linutronix.de>, <x86@kernel.org>, <seanjc@google.com>,
<pbonzini@redhat.com>, <linux-kernel@vger.kernel.org>,
<kvm@vger.kernel.org>, <peterz@infradead.org>,
<rick.p.edgecombe@intel.com>, <mlevitsk@redhat.com>,
<weijiang.yang@intel.com>, <john.allen@amd.com>
Subject: Re: [PATCH v2 4/6] x86/fpu/xstate: Introduce fpu_guest_cfg for guest FPU configuration
Date: Wed, 5 Mar 2025 16:57:50 +0800 [thread overview]
Message-ID: <Z8gSDhr1ZfIEVVgU@intel.com> (raw)
In-Reply-To: <ea73a36a-8ac5-462b-a97e-c398f6307f2f@intel.com>
On Tue, Mar 04, 2025 at 02:50:48PM -0800, Dave Hansen wrote:
>On 11/26/24 02:17, Chao Gao wrote:
>> From: Yang Weijiang <weijiang.yang@intel.com>
>>
>> Define new fpu_guest_cfg to hold all guest FPU settings so that it can
>> differ from generic kernel FPU settings, e.g., enabling CET supervisor
>> xstate by default for guest fpstate while it's remained disabled in
>> kernel FPU config.
>>
>> The kernel dynamic xfeatures are specifically used by guest fpstate now,
>> add the mask for guest fpstate so that guest_perm.__state_perm ==
>> (fpu_kernel_cfg.default_xfeature | XFEATURE_MASK_KERNEL_DYNAMIC). And
>> if guest fpstate is re-allocated to hold user dynamic xfeatures, the
>> resulting permissions are consumed before calculate new guest fpstate.
>
>This kinda restates what the code does, but I don't think it matches the
>code.
Actually, it does (see more below)
>
>> With new guest FPU config added, there're 3 categories of FPU configs in
>> kernel, the usages and key fields are recapped as below.
>
>This changelog is pretty rough. It's got a lot of words but not much
>substance.
Will revise the changelog.
[...]
>
>
>>
>> @fpu_guest_cfg.default_size
>> - size of compacted buffer with 'fpu_guest_cfg.default_features'
>
>This looks like kerneldoc, not changelog. Are you sure you want it _here_?
No, I agree this should be a comment above fpu_guest/kernel/user_cfg.
>
>
>> @@ -829,6 +835,10 @@ void __init fpu__init_system_xstate(unsigned int legacy_size)
>> fpu_user_cfg.default_features = fpu_user_cfg.max_features;
>> fpu_user_cfg.default_features &= ~XFEATURE_MASK_USER_DYNAMIC;
>>
>> + fpu_guest_cfg.max_features = fpu_kernel_cfg.max_features;
>> + fpu_guest_cfg.default_features = fpu_guest_cfg.max_features;
>> + fpu_guest_cfg.default_features &= ~XFEATURE_MASK_USER_DYNAMIC;
>
>I thought this was saying above that it was _setting_ dynamic features.
>
>Why _not_ set them by default?
At first glance, I had the same question.
XFEATURE_MASK_*KERNEL*_DYNAMIC is not excluded here, so it is enabled by
default. I believe the confusion arises partly from the order of the
patches. I will reorder the patches as you suggested in patch 5.
next prev parent reply other threads:[~2025-03-05 8:58 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 [this message]
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
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=Z8gSDhr1ZfIEVVgU@intel.com \
--to=chao.gao@intel.com \
--cc=dave.hansen@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox