Re: [PATCH] x86/kvm: Account for fpstate->user_xfeatures changes

[Tyler Stachecki <stachecki.tyler@gmail.com>]

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@redhat.com/

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