Re: [PATCH v2 2/2] s390x/cpumodel: Introduce dynamic feature groups

[Christian Borntraeger]

re-adding ccs from the cover-letter

>>> On 25.11.19 18:20, David Hildenbrand wrote:
>>>
>>> As soon as dynamic feature groups are used, the CPU model becomes
>>> migration-unsafe. Upper layers can expand these models to migration-safe
>>> and static variants, allowing them to be migrated.
>>
>> I really dislike that. I am trying to get rid of the unsafe variants (e.g. 
>> now
>> defaulting to host-model instead of host-passthrough). I do not want to give
>> users new ways of hurting themselves.
>>
> 
> Please note that this is just on the bare command line. Libvirt and friends 
> will expand the model and have proper migration in place. What exactly is 
> your concern in that regard?

What is then the value? libvirt can also use host-model or  baselining if 
necessary.
And for the command line this will just add more opportunity to shot yourself 
in the
foot, no?

Let me put it this way, I might have misunderstood what you are trying to do 
here,
but if I do not get, then others (e.g. users) will also not get it.

Maybe its just the interface or the name. But I find this very non-intuitive

e.g. you wrote

    Get the maximum possible feature set (e.g., including deprecated
    features) for a CPU definition in the configuration ("everything that
    could be enabled"):
        -cpu z14,all-features=off,available-features=on

    Get all valid features for a CPU definition:
        -cpu z14,all-features=on

What is the point of this? It is either the same as the one before, or it wont
be able to start. 

> 
>> Unless I misunderstood Eduardo, I think his versioning approach is actually 
>> better
>> in regard to migration, no?
>> I z terms, you can still say -cpu z13  which is just an alias to z13v1 z13v2 
>> etc.
>> Assuming that the version is checked this will be safe.
>>
> 
> It‘s even worse AFAIKS. A „-cpu z13“ would dynamically map to whatever is 
> best on the host.
>