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:34:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1


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.




reply via email to

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