Re: Help with Understanding vcpu xstate restore error during vm migration

[Fonyuy-Asheri Caleb <fonyuy-asheri.caleb@xxxxxxxx>]

Hello Andrew, 
Hello Jan,

Please permit me to come back to this once again. 

> On 15/07/2024 9:16 am, Jan Beulich wrote:
>> On 15.07.2024 09:38, Fonyuy-Asheri Caleb wrote:
>>>> Perhaps the more important question, are you booting the skylake with
>>>> cpuid=no-avx on the command line by any chance?
>>> No. I didn't boot any of the machines with any cpuid modification 
>>> whatsoever.
>> Yet is there perhaps "Mitigating GDS by disabling AVX" in the boot log of
>> the hypervisor (which sadly so far you didn't supply anywhere afaics)?
> 
> Oh - good point.  I'd completely forgotten about that.
> 
> If you've got out-of-date microcode (specifically microcode prior to
> 2023-08-08), then yes, Xen will disable AVX by default to mitigate
> CVE-2022-40982 / "Gather Data Sampling", and the symptoms would look
> exactly like this.
> 
> ~Andrew


I was able to obtain access to an Ice Lake Xeon processor
which is one of the processors affected by the GDS vulnerability.

I will like to know what could be the effect of this "cpuid=no-avx" xen default
on the xstates handled by the system. How does this disabling manifest itself 
between on my CPUID or list of features? 

Also, I would like to understand the relationship between xstates in xen and 
xsave
dependencies on the system? I was expecting to have more xstates once i have 
more
xsave dependencies but was surprised to notice a live migration go through from 
a 
cpu with more xsave dependencies to one with fewer dependencies(features which 
use xsave). Is there something I'm understanding wrongly? 

Lastly, during vm migration, do we consider all possible xstates or just the 
active 
xstates of the cpu? I am not able to figure that out from the code yet. 


Thank you in advance

Caleb