RE: [patch 0/6] x86/fpu: Preparatory changes for guest AMX support

Tian, Kevin
2021-12-14T07:54:12Z

> From: Liu, Jing2 <jing2.liu@linux.intel.com>
> Sent: Tuesday, December 14, 2021 2:52 PM
>
> On 12/14/2021 10:50 AM, Thomas Gleixner wrote:
> > 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.
>

There are two options to handle multiple xfd features.

a) a conservative approach as Thomas suggested, i.e. don't disable emulation
until all the features in guest_fpu::perm are requested by the guest. This
definitely has poor performance if the guest only wants to use a subset of
perm features. But functionally p.o.v it just works.

Given we only have one xfeature today, let's just use this simple check which
has ZERO negative impact.

b) an optimized approach by dynamically enabling/disabling emulation. e.g.
we can disable emulation after the 1st xfd feature is enabled and then
reenable it in #NM vmexit handler when XFD_ERR includes a bit which is
not in guest_fpu::xfeatures, sort of like:

--xfd trapped, perm has two xfd features--
(G) access xfd_feature1;
(H) trap #NM (XFD_ERR = xfd_feature1) and inject #NM;
(G) WRMSR(IA32_XFD, (-1ULL) & ~xfd_feature1);
(H) reallocate fpstate and disable write emulation for XFD;

--xfd passed through--
(G) do something...
(G) access xfd_feature2;
(H) trap #NM (XFD_ERR = xfd_feature2), enable emulation, inject #NM;

--xfd trapped--
(G) WRMSR(IA32_XFD, (-1ULL) & ~(xfd_feature1 | xfd_feature2));
(H) reallocate fpstate and disable write emulation for XFD;

--xfd passed through--
(G) do something...

Thanks
Kevin