qemu-devel
[Top][All Lists]
Advanced

[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: Mon, 13 May 2019 11:51:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1


On 13.05.19 11:40, David Hildenbrand wrote:
> On 13.05.19 11:34, Christian Borntraeger wrote:
>>
>>
>> On 13.05.19 10:03, David Hildenbrand wrote:
>>>>> +    if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < 
>>>>> S390_MAX_CPUS)
>>>>> +        mc->max_cpus = S390_MAX_CPUS - 8;
>>>>
>>>> This is too complicated, just set it always to 240.
>>>>
>>>> However, I am still not sure how to best handle this scenario. One
>>>> solution is
>>>>
>>>> 1. Set it statically to 240 for machine > 4.1
>>>> 2. Keep the old machines unmodifed
>>>> 3. Don't indicate the CPU feature for machines <= 4.0
>>>>
>>>> #3 is the problematic part, as it mixes host CPU features and machines.
>>>> Bad. The host CPU model should always look the same on all machines. I
>>>> don't like this.
>>>>
>>>
>>> FWIW, #3 is only an issue when modeling it via the CPU model, like
>>> Christian suggested.
>>>
>>> I suggest the following
>>>
>>> 1. Set the max #cpus for 4.1 to 240 (already done)
>>> 2. Keep it for the other machines unmodified (as suggested by Thomas)
>>> 3. Create the layout of the SCCB depending on the machine type (to be done)
>>>
>>> If we want to model diag318 via a CPU feature (which makes sense for
>>> migration):
>>>
>>> 4. Disable diag318 with a warning if used with a machine < 4.1
>>>
>>
>> I think there is a simpler solution. It is perfectly fine to fail the startup
>> if we cannot fulfil the cpu model. So lets just allow 248 and allow this 
>> feature 
>> also for older machines. And if somebody chooses both at the same time,
>> lets fails the startup.
> 
> To which knob do you want to glue the layout of the SCLP response? Like
> I described?  Do you mean instead of warning and masking the feature off
> as I suggested, simply failing?

The sclp response will depend on the dia318 cpu model flag. If its on, the sclp
response will have it, otherwise not.
- host-passthrough: not migration safe anyway
- host-model: if the target has diag318 good, otherwise we reject migration 
> 
> In that case, -machine ..-4.0 -cpu host will not work on new HW with new
> KVM. Just noting.

Only if you have 248 CPUs (which is unlikely). My point was to do that for all
machine levels.




reply via email to

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