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@xxxxxxxxx
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
