On 02/10/21 23:31, Thomas Gleixner wrote:
You have two options:
1) Always allocate the large buffer size which is required to
accomodate all possible features.
Trivial, but waste of memory.
2) Make the allocation dynamic which seems to be trivial to do in
kvm_load_guest_fpu() at least for vcpu->user_fpu.
The vcpu->guest_fpu handling can probably be postponed to the
point where AMX is actually exposed to guests, but it's probably
not the worst idea to think about the implications now.
Paolo, any opinions?
Unless we're missing something, dynamic allocation should not be hard to
do for both guest_fpu and user_fpu; either near the call sites of
kvm_save_current_fpu, or in the function itself. Basically adding
something like
struct kvm_fpu {
struct fpu *state;
unsigned size;
} user_fpu, guest_fpu;
to struct kvm_vcpu. Since the size can vary, it can be done simply with
kzalloc instead of the x86_fpu_cache that KVM has now.
The only small complication is that kvm_save_current_fpu is called
within fpregs_lock; the allocation has to be outside so that you can use
GFP_KERNEL even on RT kernels. If the code looks better with
fpregs_lock moved within kvm_save_current_fpu, go ahead and do it like that.
Paolo
