On 1/28/20 6:24 AM, Cornelia Huck wrote: > 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/ ? >
Correct. >> >> So, a VM can run with the original N max CPUs, but in reality we can only >> utilize n-1. > > s/we/the guest/ ? > Correct again. > With those changes, it makes sense to put your explanations into the > patch description (for later reference). > >> >>>> >>>>>> >> >> [...] >> >> > > -- Respectfully, - Collin Walling
