On Fri, 2023-11-03 at 07:33 -0700, Sean Christopherson wrote:
On Thu, Nov 02, 2023, Maxim Levitsky wrote:Seems fair.
On Wed, 2023-11-01 at 07:16 -0700, Sean Christopherson wrote:I was actually talking about
On Tue, Oct 31, 2023, Maxim Levitsky wrote:OK, I understand you now. What you claim is that it is legal to do this:
On Thu, 2023-10-26 at 10:24 -0700, Sean Christopherson wrote:I don't understand what you mean by "This".
--This might not work with kernel dynamic features, because
From: Sean Christopherson <seanjc@xxxxxxxxxx>
Date: Thu, 26 Oct 2023 10:17:33 -0700
Subject: [PATCH] x86/fpu/xstate: Always preserve non-user xfeatures/flags in
__state_perm
Fixes: 781c64bfcb73 ("x86/fpu/xstate: Handle supervisor states in XSTATE permissions")
Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
---
arch/x86/kernel/fpu/xstate.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index ef6906107c54..73f6bc00d178 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -1601,16 +1601,20 @@ static int __xstate_request_perm(u64 permitted, u64 requested, bool guest)
if ((permitted & requested) == requested)
return 0;
- /* Calculate the resulting kernel state size */
+ /*
+ * Calculate the resulting kernel state size. Note, @permitted also
+ * contains supervisor xfeatures even though supervisor are always
+ * permitted for kernel and guest FPUs, and never permitted for user
+ * FPUs.
+ */
mask = permitted | requested;
- /* Take supervisor states into account on the host */
- if (!guest)
- mask |= xfeatures_mask_supervisor();
ksize = xstate_calculate_size(mask, compacted);
xfeatures_mask_supervisor() will return all supported supervisor features.
Somewhat of a side topic, I feel very strongly that we should use "guest only"
terminology instead of "dynamic". There is nothing dynamic about whether or not
XFEATURE_CET_KERNEL is allowed; there's not even a real "decision" beyond checking
wheter or not CET is supported.
Therefore at least until we have an actual kernel dynamic feature (a featureBy "it", I assume you mean userspace?
used by the host kernel and not KVM, and which has to be dynamic like AMX),
I suggest that KVM stops using the permission API completely for the guest
FPU state, and just gives all the features it wants to enable right to
__fpu_alloc_init_guest_fpstate() (Guest FPU permission API IMHO should beKVM allocates guest FPU state during KVM_CREATE_VCPU, so not using prctl() would
deprecated and ignored)
either require KVM to defer allocating guest FPU state until KVM_SET_CPUID{,2},
or would require a VM-scoped KVM ioctl() to let userspace opt-in to
Allocating guest FPU state during KVM_SET_CPUID{,2} would get messy,
as KVM allows
multiple calls to KVM_SET_CPUID{,2} so long as the vCPU hasn't done KVM_RUN. E.g.
KVM would need to support actually resizing guest FPU state, which would be extra
complexity without any meaningful benefit.
- KVM_SET_XSAVE
- KVM_SET_CPUID (with AMX enabled)
KVM_SET_CPUID will have to resize the xstate which is already valid.
KVM_SET_CPUID2 (with dynamic user feature #1)
KVM_SET_CPUID2 (with dynamic user feature #2)
The second call through __xstate_request_perm() will be done with only user
xfeatures in @permitted and so the kernel will compute the wrong ksize.
Your patch to fix the __xstate_request_perm() does seem to be correct in aCET_KERNEL isn't dynamic! It's guest-only. There are no runtime decisions as to
sense that it will preserve the kernel fpu components in the fpu permissions.
However note that kernel fpu permissions come from
'fpu_kernel_cfg.default_features' which don't include the dynamic kernel
xfeatures (added a few patches before this one).
whether or not CET_KERNEL is allowed. All guest FPU get CET_KERNEL, no kernel FPUs
get CET_KERNEL.
That matters because I am also proposing that we add a dedicated, defined-at-boot
fpu_guest_cfg instead of bolting on a "dynamic", which is what I meant by this:
: Or even better if it doesn't cause weirdness elsewhere, a dedicatedThis is a very good idea.
: fpu_guest_cfg. For me at least, a fpu_guest_cfg would make it easier to
: understand what all is going on.
That way, initialization of permissions is simplyThis is a valid solution.
fpu->guest_perm = fpu_guest_cfg.default_features;
and there's no need to differentiate between guest and kernel FPUs when reallocating
for dynamic user xfeatures because guest_perm.__state_perm already holds the correct
data.
Therefore an attempt to resize the xstate to include a kernel dynamic feature byThis is what I am suggesting.
__xfd_enable_feature will fail.
If kvm on the other hand includes all the kernel dynamic features in the
initial allocation of FPU state (not optimal but possible),