Re: [libvirt] [Qemu-devel] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
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