On 06.08.2024 11:30, Fonyuy-Asheri Caleb wrote: > 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'
None of these require extra state (i.e. registers), hence ... > 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. ... no extra "xstates" (as you name it). > However migrating a guest from Source to target works. > > Note that these extra avx512 features are all visible to the guest I migrate. Ah yes. While that's a bug, it's a known one I think, awaiting further work that Andrew has been meaning to do for quite some time, yet always getting preempted by security stuff and other emergencies. For guests to migrate safely, I think right now it is required that you limit features visible to them on the source host. Jan
