Re: [qemu-s390x] [Qemu-devel] [PATCH 2/3] s390x/kvm: Handle bpb feature

[Halil Pasic]

On 01/17/2018 04:10 PM, David Hildenbrand wrote:
>>> As soon as we enable bits for CPU models, we guarantee that migration
>>> works. While introducing this change we already had one example where
>>> this was not the case. Not good. (and remember having another such
>>> exception)
>> The point is migration continues to work. In fact I had a different version
>> of this patch set that did it the other way around. Keep 82 a transparent
>> and add a new cpu misc facility that takes care of the migration state.
>>> It is easier to patch a feature in than silently enabling *anything*
>>> somebody thinks is transparent (but its not). Especially not for the
>>> host model. The expanded host model is migration safe.
>> I really do not care about -cpu host (host-passthrough) for migration 
>> safety, 
>> because its not. And as you said: host-model (expanded) will work.
>>
> It will if the world would be perfect.
> 
> expand "-cpu host" -> -cpu z14-base,stfle_82=on
> 
> stfle_82 would now not be properly migrated. Yes, it might work somehow
> right now. But it is not clean.
> 

Based on the code (did not test) I would expect to see this in the
scenario I think you are talking about David:

0. Libvirt uses cpu mode host (not host-passtrough).
1. Source: -"cpu host" expands to "-cpu z14-base,stfle_82=on" as you said
the whole environment (host cpu, kvm, qemu) is supporting 82 inclusive migration
2. Target: libvirt requires "-cpu z14-base,stfle_82=on" when trying to migrate
2.1. If the target environment as a whole does not fully support 82 the model
checking refuses the migration. It does not matter if the reason is QEMU missing
patch #2 or lack of HW support or whatever.
2.2 If the target environment as a whole does fully support 82 the model 
migration
works, and is safe. If the target QEMU does not have patch #2 we will end up 
here.
But we may end up here for other reasons.

Both outcomes are works as designed, as far as my understanding of the design 
goes.
Or am I wrong?

Assumed my reasoning above is correct, I really don't get what is not clean.
Except 'blindly' trusting the hardware that it works as advertised (and
fixing the mess only if it turns out that there is a mess).

On a meta level I think I understand your concerns David to some extent.
But for my taste here you are too concerned about the user shooting herself
into the foot (because equipment malfunction or user error).

Let me also note, that while we might very well end up propagating bugs
to the user, we also give the user the means to mitigate these (e.g.
by turning the buggy features explicitly off like -cpu host,stfle_82=off).

Regards,
Halil