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

[Halil Pasic <pasic@linux.vnet.ibm.com>]

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