Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support

[David Hildenbrand]

>>> But that can be tested using the runability information if I am not wrong.
>>
>> You mean the cpu level information, right?

Yes, query-cpu-definition includes for each model runability information
via "unavailable-features" (valid under the started QEMU machine).

>>
>>>
>>>> and others that we have today.
>>>>
>>>> So yes, I think this would be acceptable.  
>>>
>>> I guess it is acceptable yes. I doubt anybody uses that many CPUs in
>>> production either way. But you never know.
>>
>> I think that using that many cpus is a more uncommon setup, but I still
>> think that having to wait for actual failure
> 
> That can happen all the time today. You can easily say z14 in the xml when 
> on a zEC12. Only at startup you get the error. The question is really:

"-smp 248 -cpu host" will no longer work, while e.g. "-smp 248 -cpu z12"
will work. Actually, even "-smp 248" will no longer work on affected
machines.

That is why wonder if it is better to disable the feature and print a
warning. Similar to CMMA, where want want to tolerate when CMMA is not
possible in the current environment (huge pages).

"Diag318 will not be enabled because it is not compatible with more than
240 CPUs".

However, I still think that implementing support for more than one SCLP
response page is the best solution. Guests will need adaptions for > 240
CPUs with Diag318, but who cares? Existing setups will continue to work.

Implementing that SCLP thingy will avoid any warnings and any errors. It
just works from the QEMU perspective.

Is implementing this realistic?

> do you want to error on definition of the xml or on startup.

I actually have no idea what the best practice on the libvirt side is.
There seems to be a user for max-cpus and unavailable-features in QEMU.

And I think
> startup is the better place here. This allows to create definitions that will
> be useful in the future (pre-planning), e.g. if you know that you will update
> your machine or the code soon.



-- 

Thanks,

David / dhildenb