[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0962c143-2ff9-f157-d258-d16659818e80@redhat.com>
Date: Wed, 13 Oct 2021 08:26:36 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: "Liu, Jing2" <jing2.liu@...el.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>
Subject: Re: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core
On 13/10/21 08:15, Liu, Jing2 wrote:
> After KVM passthrough XFD to guest, when vmexit opening
> irq window and KVM is interrupted, kernel softirq path can call
> kernel_fpu_begin() to touch xsave state. This function does
> XSAVES. If guest XFD[18] is 1, and with guest AMX state in register,
> then guest AMX state is lost by XSAVES.
Yes, the host value of XFD (which is zero) has to be restored after
vmexit. See how KVM already handles SPEC_CTRL.
Passthrough of XFD is only enabled after the guest has caused an #NM
vmexit and the full XSAVE state has been dynamically allocated,
therefore it is always possible to do an XSAVES even from atomic context.
Paolo
Powered by blists - more mailing lists