On 3/7/2025 8:41 AM, Chao Gao wrote:
Define a new XFEATURE_MASK_KERNEL_DYNAMIC mask to specify the features
that can be optionally enabled by kernel components. This is similar to
XFEATURE_MASK_USER_DYNAMIC in that it contains optional xfeatures that
can allows the FPU buffer to be dynamically sized. The difference is that
the KERNEL variant contains supervisor features and will be enabled by
kernel components that need them, and not directly by the user. Currently
it's used by KVM to configure guest dedicated fpstate for calculating
the xfeature and fpstate storage size etc.
Kernel dynamic features are enabled for the guest FPU and disabled for
the kernel FPU, effectively making them guest-only features.
Set XFEATURE_CET_KERNEL as the first kernel dynamic feature, as it is
required only by the guest FPU for the upcoming CET virtualization
support in KVM.
When introducing user dynamic features, AMX required a large state, so
buffer reallocation for expansion was deferred until it was actually
used. This introduction was associated with introducing a permission
mechanism, which was expected to be requested by userspace.
For VCPU tasks, the userspace component (QEMU) requests permission [1],
and buffer expansion then follows based on the exposed CPUID
determination [2].
Now, regarding the new kernel dynamic features, I’m unsure whether this
changelog or anything else sufficiently describes its semantics
distintively. It appears that both permission grant and buffer
allocation for the kernel dynamic feature occur at VCPU allocation time.
However, this model differs from the deferred buffer expansion model for
user dynamic features.
If the kernel dynamic feature model were to follow the same deferred
reallocation approach as user dynamic features, buffer reallocation
would be expected. In that case, I'd also question whether fpu_guest_cfg
is truly necessary.
VCPU allocation could still rely on fpu_kernel_cfg, and fpu->guest_perm
could be extrapolated from fpu->perm or fpu_kernel_cfg. Then,
reallocation could proceed as usual based on the permission, extending
fpu_enable_guest_xfd_features(), possibly renaming it to
fpu_enable_dynamic_features().
That said, this is a relatively small state. Even if the intent was to
introduce a new semantic model distinct from user dynamic features, it
should be clearly documented to avoid confusion.
On the other hand, if the goal is rather to establish a new approach for
handling a previously nonexistent set of guest-exclusive features, then
the current approach remains somewhat convoluted without clear
descriptions. Perhaps, I'm missing something.
Thanks,
Chang
[1] https://github.com/qemu/qemu/blob/master/target/i386/kvm/kvm.c#L6395
[2]
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kvm/cpuid.c#n195
