lkml.org 
[lkml]   [2021]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v10 10/28] x86/fpu/xstate: Update the XSTATE save function to support dynamic states
From
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

\
 
 \ /
  Last update: 2021-10-05 09:51    [W:0.090 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site