[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH v4] s390: diagnose 318 info reset and migration support
Date: Tue, 14 May 2019 10:37:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 14.05.19 09:28, David Hildenbrand wrote:
>>>> 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?

Yes it is but it will take time. I will try to get this rolling. To make
progress on the diag318 thing, can we error on startup now and simply
remove that check when when have implemented a larger sccb? If we would
now do all kinds of "change the max number games" would be harder to "fix".

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]