Re: [libvirt] [Qemu-devel] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines

On 10/25/2017 08:13 PM, Jason J. Herne wrote: @Jason Hi Jason, I don't have access to a z14 at the moment, and since you do, I would like to try out something. I will first describe my concern, and then the test scenario. The last line above, cap_gs = 1, has the side effect of returning true ever after. int kvm_s390_get_gs(void) { return cap_gs; } Now considering static bool gscb_needed(void *opaque) { return kvm_s390_get_gs(); } const VMStateDescription vmstate_gscb = { .name = "cpu/gscb", .version_id = 1, .minimum_version_id = 1, .needed = gscb_needed, .fields = (VMStateField[]) { VMSTATE_UINT64_ARRAY(env.gscb, S390CPU, 4), VMSTATE_END_OF_LIST() } }; const VMStateDescription vmstate_s390_cpu = { .name = "cpu", .post_load = cpu_post_load, .pre_save = cpu_pre_save, .version_id = 4, .minimum_version_id = 3, .fields = (VMStateField[]) { VMSTATE_UINT64_ARRAY(env.regs, S390CPU, 16), VMSTATE_UINT64(env.psw.mask, S390CPU), VMSTATE_UINT64(env.psw.addr, S390CPU), VMSTATE_UINT64(env.psa, S390CPU), VMSTATE_UINT32(env.todpr, S390CPU), VMSTATE_UINT64(env.pfault_token, S390CPU), VMSTATE_UINT64(env.pfault_compare, S390CPU), VMSTATE_UINT64(env.pfault_select, S390CPU), VMSTATE_UINT64(env.cputm, S390CPU), VMSTATE_UINT64(env.ckc, S390CPU), VMSTATE_UINT64(env.gbea, S390CPU), VMSTATE_UINT64(env.pp, S390CPU), VMSTATE_UINT32_ARRAY(env.aregs, S390CPU, 16), VMSTATE_UINT64_ARRAY(env.cregs, S390CPU, 16), VMSTATE_UINT8(env.cpu_state, S390CPU), VMSTATE_UINT8(env.sigp_order, S390CPU), VMSTATE_UINT32_V(irqstate_saved_size, S390CPU, 4), VMSTATE_VBUFFER_UINT32(irqstate, S390CPU, 4, NULL, irqstate_saved_size), VMSTATE_END_OF_LIST() }, .subsections = (const VMStateDescription*[]) { &vmstate_fpu, &vmstate_vregs, &vmstate_riccb, &vmstate_exval, &vmstate_gscb, NULL }, }; I would expect the vmstate_gscb subsection being sent, even if gs is disabled via cpu-model if kernel and possibly machine has gs support (and qemu has cpu-models). So the test scenario I want you to play trough is the following. Take the latest-greatest qemu with this patch applied. Make sure gs works (is provided to the guest) with a 2.9 machine version, and a fully specified cpu-model. Now disable gs explicitly. Try to migrate this to another machine having a 2.9 binary. I expect the migration failing because, the subsection is going to be sent by the latest-greatest binary, but is unknown to the 2.9 binary. Notice this is despite the fact that gs is explicitly disabled. Now that I think about it, maybe the 2.9 binary is going to reject the explicit gs flag altogether, because it's unknown. Isn't this a problem? I'm afraid like this the only migration-safe variant is -base, but that would essentially make adding features incrementally impossible. But I hypothesize trying to migrate with z13 or even z13-base would also trigger the unknown subsection problem. Unfortunately I can't test this because my kernel never makes kvm_vm_enable_cap(s, KVM_CAP_S390_GS, 0) return 0, because I lack HW support in the host. Regards, Halil