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