[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Collin Walling
Subject: Re: [PATCH v6 2/2] s390: diagnose 318 info reset and migration support
Date: Mon, 27 Jan 2020 18:05:36 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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.

So, a VM can run with the original N max CPUs, but in reality we can only
utilize n-1. 



- Collin Walling

reply via email to

[Prev in Thread] Current Thread [Next in Thread]