Comment 3 for bug 2019108

This looks similar to the following kernel thread https://<email address hidden>/T/
> Apparently "size 832 != kernel_size 0" so let the debugging continue...
[...]
> So we've actually found and fixed the issue, but XSAVE and therefore
automatically gnarly.
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c3bd0b83ea5b7c0da6542687436042eeea1e7909
>
>There is no real hardware with XSAVEC but not XSAVES; the spec does try
>to distinguish the two, and it's useful for virt to offer XSAVEC without
>XSAVES.
>
>CPUID.0xd[1].ebx is spec'd as the total size for XSAVES of all current
>XCR0|XSS states. This is known dodgy already for native, as it leaks
>the current MSR_XSS setting into userspace.
>
>I had written the logic originally to hide this dynamic field if XSAVES
>wasn't enumerated, but Linux now uses it if XSAVEC is enumerated, to
>cross-check what it can see elsewhere in the CPUID state.

On a guest VM running the same hypervisor, we see the xsavec feature is present but not xsaves.

https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c3bd0b83ea5b7c0da6542687436042eeea1e7909 mentions
> While the SDM isn't very clear about this, our present behavior make
> Linux 5.19 unhappy. As of commit 8ad7e8f69695 ("x86/fpu/xsave: Support
> XSAVEC in the kernel") they're using this CPUID output also to size
> the compacted area used by XSAVEC. Getting back zero there isn't really
> liked, yet for PV that's the default on capable hardware: XSAVES isn't
> exposed to PV domains.
>
> Considering that the size reported is that of the compacted save area,
> I view Linux'es assumption as appropriate (short of the SDM properly
> considering the case). Therefore we need to populate the field also when
> only XSAVEC is supported for a guest.