lkml.org 
[lkml]   [2021]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core
Date

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

I'm trying to understand why qemu's XFD is zero after kernel supports AMX.
Do you mean in guest #NM trap KVM also alloc extra user_fpu buffer and
clear qemu's XFD? But why do we need do that?

I think only when qemu userspace requests an AMX permission and exec
AMX instruction generating host #NM, host kernel clears qemu's XFD[18].
If guest #NM being trapped, KVM *don't* need clear host's XFD, but only
allocate guest_fpu's buffer and current->thread.fpu 's buffer, and
clear guest's XFD.


> Passthrough of XFD is only enabled after the guest has caused an #NM
> vmexit

Yes, passthrough is done by two cases: one is guest #NM trapped;
another is guest clearing XFD before it generates #NM (this is possible for
guest), then passthrough.
For the two cases, we passthrough and allocate buffer for guest_fpu, and
current->thread.fpu.

Thanks,
Jing

and the full XSAVE state has been dynamically allocated, therefore it
> is always possible to do an XSAVES even from atomic context.
>
> Paolo

\
 
 \ /
  Last update: 2021-10-13 09:48    [W:0.154 / U:0.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site