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 <borntrae...@de.ibm.com> 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 <wall...@linux.ibm.com> >>>>> --- > > I'll split the patches into: 1) linux-header changes 2) CPU model changes 3) diag318 usages / migration -- Respectfully, - Collin Walling