On 10/27/2017 04:06 PM, Christian Borntraeger wrote: > > > 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) > That piece of the puzzle was missing for me (no xxx=off for M minus M-base features). > > 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. > I agree. > 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).> Noted. > 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) > Yes, I've seen that. It would be nice though if this design was easier to find in written. Unfortunately I can read minds only to a very limited extent, and the written stuff I've read did not give me a full understanding of the design -- although the entity to blame for this could be my limited intellect. > >> >> 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. > OK. I will have to learn more about this. IMHO it does not make sense to burden the community with the holes in my knowledge any more, but I will have to stuff them to feel comfortable in this area. Regards, Halil -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
