On Mon, 27 Jan 2020 18:05:36 -0500 Collin Walling <wall...@linux.ibm.com> wrote:
> 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. s/machine/guest/ ? > > So, a VM can run with the original N max CPUs, but in reality we can only > utilize n-1. s/we/the guest/ ? With those changes, it makes sense to put your explanations into the patch description (for later reference). > > >> > >>>> > > [...] > >
