> On 06.08.2024 09:34, Fonyuy-Asheri Caleb wrote:
>>> 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.
>>
>> Sorry for not specifying. I am still in the same context as stated
>> previously.
>> I haven't made any modifications to xen and no restrictions on what the guest
>> can see.
>
> Wasn't it the case that previously you observed AVX disabled, because of
> GDS? With AVX disabled, AVX512 would be implicitly disabled, too. Then
In my previous setup I wasn't able to confirm the GDS status because at the time
we mentioned it in discussions I no longer had access to the experiment
environment.
> migrating from an AVX512-capable host to an AVX512-incapable one would
> of course work. Yet of course this is only an example, because I don't
> know whether AVX512 is what your new inquiry would have been about. As
> indicated - please provide sufficient detail so we actually know what
> you're doing and what you observe.
>
> Jan
Seems there's more to this than I think. Here's the entire information about my
setup.
Source Server:
Processor: Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz
Xsave dependences(based on xen gen-cpuid.py):
'fma', 'avx', 'f16c', 'avx2', 'avx512f', 'avx512dq',
'avx512cd',
'avx512bw', 'avx512vl', 'xsaveopt', 'xsavec', 'xgetbv1',
'xsaves',
'pku', 'avx512_vbmi2', 'vaes', 'vpclmulqdq',
'avx512_vnni', 'avx512_bitalg',
'avx512_vpopcntdq'
Target Server:
Processor: Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz
Xsave dependencies:
'fma', 'avx', 'f16c', 'avx2', 'mpx', 'avx512f', 'avx512dq',
'avx512cd', 'avx512bw', 'avx512vl', 'xsaveopt', 'xsavec',
'xgetbv1', 'xsaves', 'pku'
Operating System: Debian12 (on both source and target servers)
Guest OS: Ubuntu 18.04 (PV)
Xen version: 4.18.3-pre (commit 01f7a3c792241d348a4e454a30afdf6c0d6cd71c)
So I have the following which are available on my source server but not on the
target server:
'avx512_vbmi2', 'vaes', 'vpclmulqdq', 'avx512_vnni', 'avx512_bitalg',
'avx512_vpopcntdq'
Per my current understanding, I would expect more xstates on the VM than
supported on the target
server and hence a failure with xstate verification when restoring CPU state.
However migrating a guest from Source to target works.
Note that these extra avx512 features are all visible to the guest I migrate.
Caleb
