linux-kernel - RE: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 15 Oct 2021 09:00:33 +0000
From:   "Liu, Jing2" <jing2.liu@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>
CC:     "x86@...nel.org" <x86@...nel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Arjan van de Ven" <arjan@...ux.intel.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Nakajima, Jun" <jun.nakajima@...el.com>,
        Jing Liu <jing2.liu@...ux.intel.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "Cooper, Andrew" <andrew.cooper3@...rix.com>
Subject: RE: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core


On 10/14/2021 11:01 PM, Paolo Bonzini wrote:
[...]
> Calls into the function, but doesn't necessarily allocate anything.
> What you wrote below looks correct to me, thanks.
> 

For the guest dynamic state support, based on the latest discussion,
four copies of XFD need be cared and switched, I'd like to list as follows.

- vcpu->arch.xfd: this is the real guest value for running.
Since kernel init XFD before XCR0, so I think KVM can initialize it as
bit[n]=0, for a guest start value. Otherwise, kvm_arch_vcpu_create()
need initializes vcpu->arch.xfd=guest_fpu->xfd=user_fpu->xfd=1.
Guest wrmsr XFD trap will make it update.

- user_fpu->fpstate->xfd: Qemu itself and not for guest, which is
probably always set.

- guest_fpu->fpstate->xfd: this is for KVM internal value between time[*].
KVM reinitializes it as bit[n]=0 (not the same as user_fpu), and it will be
updated when guest wrmsr trap. Thus, before passthrough, it's the same
as vcpu->arch.xfd, thus vmenter/vmexit need not rewrite msr.
After passthrough, this keeps bit[n] as 0 forever.

- current_fpu->fpstate->xfd: it should be the same as KVM internal value
between time[*].
[*] this means between kvm_load_guest_fpu and kvm_put_guest_fpu.

From guest booting timeline,  the values are: 

Booting start...   # In this time, vcpu->arch.xfd[n]=guest_fpu->xfd[n]=0
Init XFD by WRMSR(XFD[n], 1)  	# Then, vcpu->arch.xfd[n]=guest_fpu->xfd[n]=1
Init XCR0 by XSETBV 	
...
#NM WRMSR(XFD[n], 0)  # Then, guest_fpu->xfd[n]=0, vcpu->arch.xfd[n]=0.
vcpu->arch.xfd will be updated in later vmexits. 

BTW, we only need lazy-passthrough XFD WRITE and passthrough
READ directly.

Thanks,
Jing

> Paolo
> 
> > Also you really should not wait until _all_ dynamic states are cleared
> > in guest XFD.  Because a guest which has bit 18 and 19 available but
> > only > uses one of them is going to trap on every other context switch due
> to XFD writes.