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. 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. > FWIW, I think in your particular case the QEMU will reject the z14 cpu and not even come > to checking the gs. > I had a z13 cpu model in mind. I don't mention a z14 cpu-model (QEMU, not hw) in my whole email. Regards, Halil -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
