On 1/27/20 12:35 PM, Cornelia Huck wrote: > On Mon, 27 Jan 2020 11:39:02 -0500 > Collin Walling <wall...@linux.ibm.com> wrote: > >> On 1/27/20 6:47 AM, Cornelia Huck wrote: >>> On Fri, 24 Jan 2020 17:14:04 -0500 >>> Collin Walling <wall...@linux.ibm.com> wrote: >>>
[...] >>>> >>>> The availability of this instruction is determined by byte 134, bit 0 >>>> of the Read Info block. This coincidentally expands into the space used >>> >>> "SCLP Read Info" >>> >>>> for CPU entries by taking away one byte, which means VMs running with >>>> the diag318 capability will not be able to retrieve information regarding >>>> the 248th CPU. This will not effect performance, and VMs can still be >>>> ran with 248 CPUs. >>> >>> Are there other ways in which that might affect guests? I assume Linux >>> can deal with it? Is it ok architecture-wise? >>> >>> In any case, should go into the patch description :) >>> >> >> Same as above. I'll try to provide more information regarding what happens >> here in my next reply. > > I think you can lift some stuff from the cover letter. > Here's what I found out: Each CPU entry holds info regarding the CPU's address / ID as well as an indication of the availability of certain CPU features. With these patches, we lose a CPU entry for one CPU (essentially what would be the CPU at the tail-end of the list). This CPU exists, but is essentially in limbo... the machine cannot access any information regarding it. So, a VM can run with the original N max CPUs, but in reality we can only utilize n-1. >> >>>> [...] -- Respectfully, - Collin Walling
