Re: [PATCH v6 2/2] s390: diagnose 318 info reset and migration support

[Cornelia Huck]

On Mon, 27 Jan 2020 18:05:36 -0500
Collin Walling <address@hidden> wrote:

> On 1/27/20 12:35 PM, Cornelia Huck wrote:
> > On Mon, 27 Jan 2020 11:39:02 -0500
> > Collin Walling <address@hidden> wrote:
> >   
> >> On 1/27/20 6:47 AM, Cornelia Huck wrote:  
> >>> On Fri, 24 Jan 2020 17:14:04 -0500
> >>> Collin Walling <address@hidden> 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).

> 
> >>  
> >>>>  
> 
> [...]
> 
>