On Thu, Sep 14, 2023 at 04:15:54AM -0300, Leonardo Bras wrote: > So, IIUC, the xfeatures from the source guest will be different than the > xfeatures of the target (destination) guest. Is that correct? Correct. > It does not seem right to me. I mean, from the guest viewpoint, some > features will simply vanish during execution, and this could lead to major > issues in the guest. My assumption is that the guest CPU model should confine access to registers that make sense for that (guest) CPU. e.g., take a host CPU capable of AVX-512 running a guest CPU model that only has AVX-256. If the guest suddenly loses the top 256 bits of %zmm*, it should not really be perceivable as %ymm architecturally remains unchanged. Though maybe I'm being too rash here? Is there a case where this assumption breaks down? > The idea here is that if the target (destination) host can't provide those > features for the guest, then migration should fail. > > I mean, qemu should fail the migration, and that's correct behavior. > Is it what is happening? Unfortunately, no, it is not... and that is biggest concern right now. I do see some discussion between Peter and you on this topic and see that there was an RFC to implement such behavior stemming from it, here: https://lore.kernel.org/qemu-devel/20220607230645.53950-1-peterx@xxxxxxxxxx/ ... though I do not believe that work ever landed in the tree. Looking at qemu's master branch now, the error from kvm_arch_put_registers is just discarded in do_kvm_cpu_synchronize_post_init... ``` static void do_kvm_cpu_synchronize_post_init(CPUState *cpu, run_on_cpu_data arg) { kvm_arch_put_registers(cpu, KVM_PUT_FULL_STATE); cpu->vcpu_dirty = false; } ``` Best, Tyler
