[Top][All Lists]

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

Re: [qemu-s390x] [Qemu-devel] [PATCH v1] s390: guest support for diagnos

From: Collin Walling
Subject: Re: [qemu-s390x] [Qemu-devel] [PATCH v1] s390: guest support for diagnose 318 and limit max VCPUs to 247
Date: Wed, 5 Dec 2018 09:58:37 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 12/5/18 6:57 AM, David Hildenbrand wrote:
> On 05.12.18 12:54, Cornelia Huck wrote:
>> On Wed, 5 Dec 2018 09:27:44 +0100
>> Christian Borntraeger <address@hidden> wrote:
>>> On 05.12.2018 09:26, David Hildenbrand wrote:
>>>> On 04.12.18 23:18, Collin Walling wrote:  
>>>>> Add migration and reset support for diagnose 318. This is a new z14 GA2 
>>>>> hardware feature, but we can provide guest support starting with the 
>>>>> zEC12-full CPU model.
>>>>> Because new hardware introduces a new facility-availability byte in 
>>>>> the Read SCP Info block, we lose one byte in the CPU entries list 
>>>>> and must limit the maximum VCPUs to 247 (down from 248).  
>>>> This could break setups that upgrade/migrate. At least forward migration
>>>> can be broken. Do we care about that?  
>>> Can we maybe bind this feature and the cpu limit to the 4.0 machine?
>> I think that would make sense.
> Won't be that easy, as we'll have different sizes of the struct size.
> Something that might uglify the code quite a bit.
> Also we'll get a dependence between the cpu model features (e.g. probed
> via the NULL machine) and the compat machine. Have to think about this.

Are you referring to the struct CPUS390XState? Could we get away by adding
a one-byte "unused" field after the bitmap?

>>>> Can you split off
>>>> 1. linux-header changes
>>>> 2. CPU model changes? (introduction and definition of new feature, but
>>>> not when it is used?)
>>>>> Signed-off-by: Collin Walling <address@hidden>
>>>>> ---

I'll split the patches into:

1) linux-header changes
2) CPU model changes
3) diag318 usages / migration

- Collin Walling

reply via email to

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