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] [day] [month] [year] [list]

Message-ID: <BL0PR11MB3252E976B4A300F1AADA37A6A99F9@BL0PR11MB3252.namprd11.prod.outlook.com>
Date:   Mon, 22 Nov 2021 08:50: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>,
        "Tian, Jun J" <jun.j.tian@...el.com>
Subject: RE: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core

Hi Paolo,

> On 10/14/2021 7:39 PM, Paolo Bonzini wrote:
> 
> On 14/10/21 13:30, Liu, Jing2 wrote:
> > I guess we're worrying about is when KVM is sched_out, a nonzero
> > XFD_ERR can be lost by other host thread. We can save guest XFD_ERR in
> > sched_out and restore before next vmenter. Kernel is assumed not using
> > AMX thus softirq won't make it lost.
> > I think this solves the problem. So we can directly passthrough RW of
> > it, and no need to rdmsr(XFD_ERR) in vmexit.
> 
> Correct; you can also use the "user-return MSRs" machinery (until Linux
> starts using AMX in the kernel, but that shouldn't happen too soon).
> 
Thanks for the suggestion. For user-return MSR mechanism using by emulated 
MSRs, it calls kvm_set_user_return_msr() to wrmsr of guest value, update curr
value and switch host once kernel exit to userspace. 

For XFD_ERR, it's automatically changed by H/W in guest, so KVM need correctly 
update guest XFD_ERR value at a time, which is different from other user-return
MSRs, e.g., at KVM preemption and kvm_put_guest_fpu() time, and both cases 
need not do wrmsr. And for kvm_put_guest_fpu(), it does return to userspace.
Also, XFD_ERR cannot refer to vmx->guest_uret_msrs_loaded to update before 
vmenter, since curr may not an up-to-date value. My feeling is the mechanism
may not much suitable for this case and need special handling.

Since guest non-zero XFD_ERR is rare case at vmexit, how about saving XFD_ERR
when preemption, mark flag=true and restore if non-zero before vcpu enter? This 
seems simple and direct way, drawback is if XFD_ERR is not changed when schedule
out, KVM need a wrmsr, but this only happens when it's non-zero&&flag=true.

Thanks,
Jing

> Paolo