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

[Christian Borntraeger]

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.

 
>> 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
>