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" <>
To:     Paolo Bonzini <>,
        Thomas Gleixner <>,
        LKML <>
CC:     "" <>,
        "Bae, Chang Seok" <>,
        Dave Hansen <>,
        "Arjan van de Ven" <>,
        "" <>,
        "Nakajima, Jun" <>,
        Jing Liu <>,
        "" <>,
        "Cooper, Andrew" <>
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.


> 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.

Powered by blists - more mailing lists