Messages in this thread | | | Date | Tue, 14 Dec 2021 14:52:18 +0800 | Subject | Re: [patch 0/6] x86/fpu: Preparatory changes for guest AMX support | From | "Liu, Jing2" <> |
| |
Hi Thomas,
On 12/14/2021 10:50 AM, Thomas Gleixner wrote: > Folks, > > this is a follow up to the initial sketch of patches which got picked up by > Jing and have been posted in combination with the KVM parts: > > https://lore.kernel.org/r/20211208000359.2853257-1-yang.zhong@intel.com > > This update is only touching the x86/fpu code and not changing anything on > the KVM side. > > BIG FAT WARNING: This is compile tested only! > > In course of the dicsussion of the above patchset it turned out that there > are a few conceptual issues vs. hardware and software state and also > vs. guest restore. > > This series addresses this with the following changes vs. the original > approach: > > 1) fpstate reallocation is now independent of fpu_swap_kvm_fpstate() > > It is triggered directly via XSETBV and XFD MSR write emulation which > are used both for runtime and restore purposes. > > For this it provides two wrappers around a common update function, one > for XCR0 and one for XFD. > > Both check the validity of the arguments and the correct sizing of the > guest FPU fpstate. If the size is not sufficient, fpstate is > reallocated. > > The functions can fail. > > 2) XFD synchronization > > KVM must neither touch the XFD MSR nor the fpstate->xfd software state > in order to guarantee state consistency. > > In the MSR write emulation case the XFD specific update handler has to > be invoked. See #1 > > If MSR write emulation is disabled because the buffer size is > sufficient for all use cases, i.e.: > > guest_fpu::xfeatures == guest_fpu::perm > The buffer size can be sufficient once one of the features is requested since kernel fpu realloc full size (permitted). And I think we don't want to disable interception until all the features are detected e.g., one by one.
Thus it can be guest_fpu::xfeatures != guest_fpu::perm.
Thanks, Jing
| |