lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 21 Sep 2021 16:52:16 +0200 From: Vitaly Kuznetsov <vkuznets@...hat.com> To: Sean Christopherson <seanjc@...gle.com> Cc: Paolo Bonzini <pbonzini@...hat.com>, Wanpeng Li <wanpengli@...cent.com>, Jim Mattson <jmattson@...gle.com>, Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, Reiji Watanabe <reijiw@...gle.com> Subject: Re: [PATCH v2 06/10] KVM: x86: Fold fx_init() into kvm_arch_vcpu_create() Sean Christopherson <seanjc@...gle.com> writes: > Move the few bits of relevant fx_init() code into kvm_arch_vcpu_create(), > dropping the superfluous check on vcpu->arch.guest_fpu that was blindly > and wrongly added by commit ed02b213098a ("KVM: SVM: Guest FPU state > save/restore not needed for SEV-ES guest"). I have more questions to the above mentioned commit: why is it OK to 'return 0' from kvm_vcpu_ioctl_x86_set_xsave() without writing anything to 'guest_xsave'? Same goes to kvm_arch_vcpu_ioctl_get_fpu(). Whould't it be better to throw an error as we can't actually get this information for encrypted guests? It's probably too late to change this now I suppose ... > > Note, KVM currently allocates and then frees FPU state for SEV-ES guests, > rather than avoid the allocation in the first place. While that approach > is inarguably inefficient and unnecessary, it's a cleanup for the future. > > No functional change intended. > > Signed-off-by: Sean Christopherson <seanjc@...gle.com> > --- > arch/x86/kvm/x86.c | 16 ++++------------ > 1 file changed, 4 insertions(+), 12 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 6fd3fe21863e..ec61b90d9b73 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -10614,17 +10614,6 @@ static int sync_regs(struct kvm_vcpu *vcpu) > return 0; > } > > -static void fx_init(struct kvm_vcpu *vcpu) > -{ > - if (!vcpu->arch.guest_fpu) > - return; > - > - fpstate_init(&vcpu->arch.guest_fpu->state); > - if (boot_cpu_has(X86_FEATURE_XSAVES)) > - vcpu->arch.guest_fpu->state.xsave.header.xcomp_bv = > - host_xcr0 | XSTATE_COMPACTION_ENABLED; > -} > - > void kvm_free_guest_fpu(struct kvm_vcpu *vcpu) > { > if (vcpu->arch.guest_fpu) { > @@ -10703,7 +10692,10 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) > pr_err("kvm: failed to allocate vcpu's fpu\n"); > goto free_user_fpu; > } > - fx_init(vcpu); > + fpstate_init(&vcpu->arch.guest_fpu->state); > + if (boot_cpu_has(X86_FEATURE_XSAVES)) > + vcpu->arch.guest_fpu->state.xsave.header.xcomp_bv = > + host_xcr0 | XSTATE_COMPACTION_ENABLED; > > vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu); > vcpu->arch.reserved_gpa_bits = kvm_vcpu_reserved_gpa_bits_raw(vcpu); Reviewed-by: Vitaly Kuznetsov <vkuznets@...hat.com> -- Vitaly
Powered by blists - more mailing lists