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

On 10/27/2017 03:40 PM, Halil Pasic wrote: > > > On 10/27/2017 02:57 PM, Christian Borntraeger wrote: >> >> >> On 10/27/2017 02:45 PM, Christian Borntraeger wrote: >>> >>> >>> On 10/27/2017 02:31 PM, Halil Pasic wrote: >>> 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? >>> >>> No. This is exactly the _solution_ and not the problem. The target will reject >>> unknown cpu features and migration will be aborted. This is exactly what the CPU >>> model is for. > > I'm not sure we talk abut the same thing. I'm talking about the following. I > want to disable a cpu-model feature for the sake of migration (because I know > that binary version X does not support the feature, because it does not know > about it). Now if I do it via let's say -cpu z13,gs=off on let's say 2.11, > and start with the exact same command line (-cpu z13,gs=off) on lets say 2.9 > my migration will explode because of the unknown feature I'm specifying > not to be used. The migration will be rejected because the target qemu will not startup. You can easily simulate that, e.g. by doing qemu-system-s390x -cpu z13,notyetknown=off qemu-system-s390x: can't apply global z13-s390x-cpu.notyetknown=off: Property '.notyetknown' not found But libvirt will not use a full model (and the disable things) instead it will use the base model and add things. (So libvirt should never use xxx=off)

I think this is really not an issue. If you specify a feature that is not known then QEMU will not start on the target and migration is rejected. The guest continues to run on the source. So if you specify a "too new" facility yourself its really a user error. Everything that uses an explicit model (e.g. -cpu z13 or -cpu,sief2=on) will work, but only as long as the conditions are met. If you specify -cpu z14, it does not matter if it fails if the kernel or QEMU is too old, or if you just happen to run on a z13. The only question is/was: what is about "host-model". With my patch (+ the gs fixup) the following things will work: - host-model will work on z13 - host-model will work on z14 (any machine version) - host model on z13 and then migrating to z14 will work (any machine version) - host model on z13 and then migrating to z14 and then migrating back will work (any version) - qemu with fixup + host model on z14 with machine version 2.10 can be migrated The only thing that does not work is - qemu with fixup + host model on z14 with machine 2.9 can not be migrated to qemu 2.9 on z14.

Now: this would have not worked anyway, because qemu 2.9 does not know z14. So in theory QEMU must forbit z14 for compat machines (which we do not know).>

I talked to several people and it seems that on x86 the host model will also enable new features that are not known by older QEMUs and its considered works as designed. (see also Jiris mail)

> > Well I'm not sure what I describe is relevant. My thinking is along the lines > some features are added incrementally. How do use those of the features not included > in -base model which both of my environments support and disable those that > are unsupported by one of the environments. > > I will think about it some more. I've asked Boris about this situation, > and he did not put my mind at ease (to be more precise he seemed to > see this as a potential problem too), so I've decided to mention it. > Sorry if I've generated some unnecessary noise. > > I think the root of the problem is that I don't understand the difference between > z13-base and z13, and the associated rules and expected/intended usages. z13-base contains only those features that a guaranteed to be there (there is the list of non-hypervisor managed features). z13 is z13-base + all features that will be available in a reasonably recent kernel+qemu combination and make sense to be there a default. So it might happen that you cannot start -cpu z14, e.g. if you run on a kernel < 4.12.