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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.08.2024 09:04, Fonyuy-Asheri Caleb wrote:
>> 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.
> 
> 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? 

Here and ...

> 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. 

... here everything depends on what the guest gets to see. I.e. in your wording
"possible" would mean "possible from the guest's perspective", i.e. what it sees
when it executes CPUID insns with respective inputs. During migration we cannot
go below that, but we certainly can go below what the host may support.

If what you say in the earlier paragraph was the case with upstream Xen and
without you restricting what the guest being migrated was able to see on the
source host, then I think that would indicate a bug somewhere. Yet you don't
provide enough details to be certain.

Jan