Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c2f89d0b-4d85-5cfe-7718-1e70a1cc9e8e@oracle.com>
Date:   Thu, 3 Mar 2022 09:31:40 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.1
Subject: Re: [PATCH v4 02/10] crash hp: Introduce CRASH_HOTPLUG configuration
 options
Content-Language: en-US
To:     Baoquan He <bhe@redhat.com>, David Hildenbrand <david@redhat.com>
Cc:     linux-kernel@vger.kernel.org, x86@kernel.org,
        kexec@lists.infradead.org, ebiederm@xmission.com,
        dyoung@redhat.com, vgoyal@redhat.com, tglx@linutronix.de,
        mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
        hpa@zytor.com, nramas@linux.microsoft.com, thomas.lendacky@amd.com,
        robh@kernel.org, efault@gmx.de, rppt@kernel.org,
        konrad.wilk@oracle.com, boris.ostrovsky@oracle.com
References: <20220209195706.51522-1-eric.devolder@oracle.com>
 <20220209195706.51522-3-eric.devolder@oracle.com>
 <YhWpF/Cj/V+Cx6+d@MiWiFi-R3L-srv>
 <10d67f14-c5fe-0a17-e8b5-97702823cc1c@oracle.com>
 <f23efdc0-20c8-ccfd-f54d-69a9b4ee531f@redhat.com>
 <YiCW8gEb3n1CpI6x@MiWiFi-R3L-srv>
 <5b0a9bac-cd00-35df-8e55-44624729015f@redhat.com>
 <YiCvomsNsTrx0dhR@MiWiFi-R3L-srv>
From:   Eric DeVolder <eric.devolder@oracle.com>
In-Reply-To: <YiCvomsNsTrx0dhR@MiWiFi-R3L-srv>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VDhHSzNpWThKRU5scUt3dUIrenMvTURXWkhmdVBkMjhudnB0c20wYkk2NE9o?=
 =?utf-8?B?SU5POXRJU0F1Q2hGcWdhQld6V051bnUzSW4zSmorcVMzcFZSSUlIM2QvTHNF?=
 =?utf-8?B?SC9HZUMraWFvRWVzaVJ2UnFUaWp0RG1qb1J4TXpMVWREUW52VHJxN3E3V0Ru?=
 =?utf-8?B?b1VaMGs3c2xrQ2VhdE9ZbWlSTHRXNkhDK3o1Z2RtU1hGbnM5MzFOK1grUm5G?=
 =?utf-8?B?OWQ4Q0hoaWhzUXQ0c1pPWUlicGVuVVo4dXZCcStFYUxNWUlQWlV6WC9DMmJO?=
 =?utf-8?B?NDJCZXVHWVEzQi9MYitrR2EzSTVoNXd5ZTlrRVdnNkhkSUdyVk0zSzNHQ2Iy?=
 =?utf-8?B?OGV1bk1ZTnZpakxoaDN2U1RCd0ZhRzBzdmphNDBWUFQ3ZEF4OTZzeTVBOFZU?=
 =?utf-8?B?QlF4OG15QWZRcHQwSVR4T3UxSUpTdStMRy90UTlBY3NZZzRVdXR2MGZJbVJG?=
 =?utf-8?B?dTVZcUFnZmlNWjNuSDNFeVJsUEpnVGllc3ZEUmJTYzlzK242cWNadE05V3JC?=
 =?utf-8?B?WmdTRGd3TjdFeG1KM1RNcmxaSCtVbTVGUHhxbHNmZUxCVTBlejQrRWEwQXF6?=
 =?utf-8?B?ZkdZK0poaEpJNU14cXNyRjBQelUyZm5FOFdEek9sRzAzZkVVMnUrRnJsK09z?=
 =?utf-8?B?MXRRZm0yVFIwSHRUc2hCWFRGOHlzUFpYaEpzUVJPbDBDV2dYa2RMYUg2VnE2?=
 =?utf-8?B?M3V5amFYY1ZmRjE3ZjhGQ3N5bTlpekR6R3dVVU4va2FPblZFdDZpNTdyQ3BB?=
 =?utf-8?B?R0ozQWdPM09JcVkyVlpoZUF3ZzZWV2pPdG1MWUd3eGRiWnYxakd1V0pRZURW?=
 =?utf-8?B?RXlJVW5vZ3N4eFNMMXVldlNhMi9WK3dHYU5BMmpYcTJYT2daWXNCMURyb2NH?=
 =?utf-8?B?ZjlsYkNtaWF6YVhWRmhmazA2bjNrQ2dqdk9nV3N4L0RkMjk4SGh2RHlMcjFv?=
 =?utf-8?B?RUxWanJrRDRZOHd1cFAvVk1mUVBnMTdhNmJDcDFlUENOVXBTblQ2dzRIOUMx?=
 =?utf-8?B?VFpicEMrWk1qT2FNblJJd0J4N3FPUWkybHNxcU9ZRGdnTjA1WXFYOUdCUlZw?=
 =?utf-8?B?QjZRVEtVNVhWWEFZaTY5czdaak83OXBKUHo0eXVFd3d4UFRZYTUvN2FxUTNV?=
 =?utf-8?B?V29URTdEZEt2SHdtS3Z6aGpId1pZdURISHNYdGhTcDQvTGRXTDduSUFSbnZy?=
 =?utf-8?B?dS9zWStiWHIycTVZc3R0NEFpb0hEamMxY2gxSXI4VFlyN3l3cFNFaUY3T3RQ?=
 =?utf-8?B?VmRUMVEyeTdhSXpZeXo5VzRBUXNtMnJVckJUMkZseWVJTlpXZGpMdVRqYzVK?=
 =?utf-8?B?ZUlnYm5iekpiM2o5UnN1QUlSVkwxTnlDaFBaN2dTc3ZXb0pCeXlnT3FkeVFH?=
 =?utf-8?B?a3h0aVNCRTVlTHpsRjAzalpwbm1TU3FwRzVoWThnZ2NoT0FqSUJBZGFHT290?=
 =?utf-8?B?QWd2NkJzb3ZqMGFKdkNSd0Q1U3gzWjI5YnlYVFp6VWJyenlKTjBsQUV0d2dr?=
 =?utf-8?B?NW5aeStyRVJhUlpoVXFKL3dXSWZYRWtBclEvM055QXV1ajROMW1odk1Pc2RW?=
 =?utf-8?B?UVQ2b3FoV2hmVklBMXdZSTc3SWYyNlJabEM1eW91UkxHU3FvQ3R0VlVJRlUr?=
 =?utf-8?B?SXdnREtyMkV1VVFJQWtkZUgzQVd1ejYya1dpWEVHWXJJY2ZYQ3o2bHJJNXNt?=
 =?utf-8?B?Z081ME1MWlo3NS9OeFhmNEJNdU5jVFd5Q20va1hRY2F2VG5rd1VjSlNCYUJW?=
 =?utf-8?B?WnNSK1poYjl1SVpSNWdXT3BIdTBVL1AyUm5pU2FrWCtLdlZPVnVVYWp5MndV?=
 =?utf-8?B?SzNPTEF0d1BybFJxQnBTK3VmY0JRVmFZSzBMaDdGaGswYWplMUt6SWlzZk1x?=
 =?utf-8?B?RDV4RWM2MlNGdHJEc0VFdTFRQ1d3dW15VEt4L2U5cUY1eG5DSHhTWWNqN3Fs?=
 =?utf-8?B?K0VNdTFnZjdtVTI1SU0rTXZYOUlaSXlxYmN3blEyMEJnMzY1SUpPOFRnM0R1?=
 =?utf-8?B?VGlrZFpFQzdSNXVzc3E5RCtwbTByek5sYXVScldYUHdiSjhkTGxra2luQ2lz?=
 =?utf-8?B?YitkbUJVc0tlSW03OERNS08wU29lWk1WMUlNQnlOWm9TZXdIMDhkZ1ZNWEd1?=
 =?utf-8?B?eHpob1pta2tkL09xUERBOTYxQ1VhcG0vcjNocDZmVGJhM2lPYTVXZXBVUStG?=
 =?utf-8?B?OXM3bTV3bWVLUjhuTEV4SVlXb2J3eFU1bkVaa25MOVlEblVBVlQzQlhiMEE4?=
 =?utf-8?B?alEvRUZBYXhvelZmeFNxTk94cTQ0MFZZMUdlVWNoZjc2b29TRElFZnpnSFpZ?=
 =?utf-8?Q?Yp79NqmcapnDhZLH2c?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 328cf7f8-4e2a-4323-42be-08d9fd2aeddf
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4531.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2022 15:31:47.3733
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Xv8TeMs7kKO4dEt9ifesusobdiQT1jrzHA6mdpCnFjwFued1+5yOLb4chF7QD58j6yWbQkZJN6go8HgzTGnv1B2Ik+CAbkIutHuZW8aezFM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB4901
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10275 signatures=686983
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 phishscore=0
 malwarescore=0 mlxscore=0 suspectscore=0 spamscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2203030074
X-Proofpoint-ORIG-GUID: Yn_PMj7iJZUSTpoVYNFz4NlAE1T5QO2n
X-Proofpoint-GUID: Yn_PMj7iJZUSTpoVYNFz4NlAE1T5QO2n
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 3/3/22 06:08, Baoquan He wrote:
> On 03/03/22 at 12:36pm, David Hildenbrand wrote:
>> On 03.03.22 11:22, Baoquan He wrote:
>>> On 03/02/22 at 10:20am, David Hildenbrand wrote:
>>>> On 01.03.22 21:04, Eric DeVolder wrote:
>>>>>
>>>>>
>>>>> On 2/22/22 21:25, Baoquan He wrote:
>>>>>> On 02/09/22 at 02:56pm, Eric DeVolder wrote:
>>>>>>> Support for CPU and memory hotplug for crash is controlled by the
>>>>>>> CRASH_HOTPLUG configuration option, introduced by this patch.
>>>>>>>
>>>>>>> The CRASH_HOTPLUG_ELFCOREHDR_SZ related configuration option is
>>>>>>> also introduced with this patch.
>>>>>>>
>>>>>>> Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
>>>>>>> ---
>>>>>>>    arch/x86/Kconfig | 26 ++++++++++++++++++++++++++
>>>>>>>    1 file changed, 26 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>>>>>>> index ebe8fc76949a..4e3374edab02 100644
>>>>>>> --- a/arch/x86/Kconfig
>>>>>>> +++ b/arch/x86/Kconfig
>>>>>>> @@ -2060,6 +2060,32 @@ config CRASH_DUMP
>>>>>>>    	  (CONFIG_RELOCATABLE=y).
>>>>>>>    	  For more details see Documentation/admin-guide/kdump/kdump.rst
>>>>>>>    
>>>>>>> +config CRASH_HOTPLUG
>>>>>>> +	bool "kernel updates of crash elfcorehdr"
>>>>>>> +	depends on CRASH_DUMP && (HOTPLUG_CPU || MEMORY_HOTPLUG) && KEXEC_FILE
>>>>>>> +	help
>>>>>>> +	  Enable the kernel to update the crash elfcorehdr (which contains
>>>>>>> +	  the list of CPUs and memory regions) directly when hot plug/unplug
>>>>>>> +	  of CPUs or memory. Otherwise userspace must monitor these hot
>>>>>>> +	  plug/unplug change notifications via udev in order to
>>>>>>> +	  unload-then-reload the crash kernel so that the list of CPUs and
>>>>>>> +	  memory regions is kept up-to-date. Note that the udev CPU and
>>>>>>> +	  memory change notifications still occur (however, userspace is not
>>>>>>> +	  required to monitor for crash dump purposes).
>>>>>>> +
>>>>>>> +config CRASH_HOTPLUG_ELFCOREHDR_SZ
>>>>>>> +	depends on CRASH_HOTPLUG
>>>>>>> +	int
>>>>>>> +	default 131072
>>>>>>> +	help
>>>>>>> +	  Specify the maximum size of the elfcorehdr buffer/segment.
>>>>>>> +	  The 128KiB default is sized so that it can accommodate 2048
>>>>>>> +	  Elf64_Phdr, where each Phdr represents either a CPU or a
>>>>>>> +	  region of memory.
>>>>>>> +	  For example, this size can accommodate hotplugging a machine
>>>>>>> +	  with up to 1024 CPUs and up to 1024 memory regions (e.g. 1TiB
>>>>>>> +	  with 1024 1GiB memory DIMMs).
>>>>>>
>>>>>> This example of memory could be a little misleading. The memory regions
>>>>>> may not be related to memory DIMMs. System could split them into many
>>>>>> smaller regions during bootup.
>>>>>
>>>>> I changed "with 1024 1GiB memory DIMMs" to "with 1024 1GiB hotplug memories".
>>>>> eric
>>>>
>>>> It's still not quite precise. Essentially it's the individual "System
>>>> RAM" entries in /proc/iomem
>>>>
>>>> Boot memory (i.e., a single DIMM) might be represented by multiple
>>>> entries due to rearranged holes (by the BIOS).
>>>>
>>>> While hoplugged DIMMs (under virt!) are usually represented using a
>>>> single range, it can be different on physical machines. Last but not
>>>> least, dax/kmem and virtio-mem behave in a different way.
>>>
>>> Right. How about only mentioning the 'System RAM' entries in /proc/iomem
>>> as below? It's just giving an example, talking about the details of
>>> memory regions from each type may not be necessry here. People
>>> interested can refer to code or document related to get it.
>>>
>>>
>>> + default 131072
>>> + help
>>> +   Specify the maximum size of the elfcorehdr buffer/segment.
>>> +   The 128KiB default is sized so that it can accommodate 2048
>>> +   Elf64_Phdr, where each Phdr represents either a CPU or a
>>> +   region of memory.
>>> +   For example, this size can accommodate hotplugging a machine
>>> +   with up to 1024 CPUs and up to 1024 memory regions which are
>>>      represented by 'System RAM' entries in /proc/iomem.
>>
>> Maybe changing the last paragraph to:
>>
>> "For example, this size can accommodate a machine with up to 1024 CPUs
>> and up to 1024 memory regions, for example, as represented by 'System
>> RAM' entries in /proc/iomem."
> 
> Yeah, this looks good. Can the 2nd 'for example' be removed or replaced
> with 'e.g'? Please ignore it if it's normal to have two 'for example' in
> one sentence, just gentlely ask.
> 
Great, I will make the change to the text as agreed upon here!
eric