On 03/10/21 00:54, Bae, Chang Seok wrote:
FWIW, the proposed KVM patch for AMX looks to take (1) here [1] and
Paolo said [2]:
Most guests will not need the whole xstate feature set. So perhaps you
could set XFD to the host value | the guest value, trap #NM if the
host XFD is zero, and possibly reflect the exception to the guest's XFD
^^^^
(better: if the host XFD is nonzero, and the guest XCR0 includes any bit
whose state is optional).
and XFD_ERR.
This comment is about letting arch/x86/kernel resize current->thread.fpu
while the guest runs. It's not necessary before KVM supports AMX,
because KVM will never let a guest set XCR0[18] (__kvm_set_xcr).
Thomas instead was talking about allocation of vcpu->arch.guest_fpu and
vcpu->arch.user_fpu.
For dynamic allocation in kvm_save_current_fpu, you can retrieve the
XINUSE bitmask (XGETBV with RCX=1). If it contains any bits that have
optional state, you check if KVM's vcpu->arch.guest_fpu or
vcpu->arch.user_fpu are already big enough, and if not do the reallocation.
If X86_FEATURE_XGETBV1 is not available, you will not need to resize.
If XFD is supported but X86_FEATURE_XGETBV1 is not, you can just make
kvm_arch_init fail with -ENODEV. It's a nonsensical combination.
Thanks,
Paolo
In addition, loading the guest XFD MSRs should use the MSR autoload
feature (add_atomic_switch_msr).
And then I guess discussion goes on..
