From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60079C5472F for ; Tue, 27 Aug 2024 15:46:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC08D6B007B; Tue, 27 Aug 2024 11:46:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E70B36B0083; Tue, 27 Aug 2024 11:46:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5F4A6B008C; Tue, 27 Aug 2024 11:46:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B7C7D6B007B for ; Tue, 27 Aug 2024 11:46:21 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3CEDD1C544C for ; Tue, 27 Aug 2024 15:46:21 +0000 (UTC) X-FDA: 82498452162.19.83E554D Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf09.hostedemail.com (Postfix) with ESMTP id 6449F140036 for ; Tue, 27 Aug 2024 15:46:18 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724773536; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=e7Qsci5XZypKtAPC52Wd714D4qMZAJ2zMp1XBpTn3XA=; b=jnKDauZJEzs5Bs5IYLz7ZmIjs0AXyiovxJ1d7PljfpJLTV6cPHbHf+Nd3yHqk9qkmg9H+z lQMej0LUb6kHexwyUuTO1KBbfwwgJSogXdUNXcdrQ4+28Y7XTnT/KWb1hTEHJ0PZVsxTDh Pwv/1MJs3ESo4z078k3HUzvM2lB1dl8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724773536; a=rsa-sha256; cv=none; b=zG6ubxzxcLuR4mk/5maMtrsqiiOXdP6rky5CS9bkpSPf86XCQmVFbAVTRVkIFhUBiwIqdz U728h5gyD+DLWBPQ6EmkhqnFivysY3uI9uHwthzFwZkK6zg28GdfVnyg0txObf2Lp+L2pu H4ZoWy3/y5yAyL9TrXiyFplpOZ4KAW4= Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4WtWym5vKrz6DBht; Tue, 27 Aug 2024 23:42:56 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id BEA9C140447; Tue, 27 Aug 2024 23:46:11 +0800 (CST) Received: from localhost (10.203.177.66) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 27 Aug 2024 16:46:11 +0100 Date: Tue, 27 Aug 2024 16:46:10 +0100 From: Jonathan Cameron To: Shiyang Ruan CC: , , , , , , , , , , , , , , , , Subject: Re: [PATCH v4 1/2] cxl/core: introduce device reporting poison hanlding Message-ID: <20240827164610.00002f4d@Huawei.com> In-Reply-To: <20240808151328.707869-2-ruansy.fnst@fujitsu.com> References: <20240808151328.707869-1-ruansy.fnst@fujitsu.com> <20240808151328.707869-2-ruansy.fnst@fujitsu.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.177.66] X-ClientProxiedBy: lhrpeml100002.china.huawei.com (7.191.160.241) To lhrpeml500005.china.huawei.com (7.191.163.240) X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 6449F140036 X-Stat-Signature: p893zdx9a1qiudww1myxsr3eciy8t6fe X-HE-Tag: 1724773578-15747 X-HE-Meta: U2FsdGVkX1/j60U5dEHClupenBZU/TIKpCyJmSgu5p27tkhYsa8UMM/bxH09WfJjOfxX7AfcEQMZlngcXOyHfd/NPvespd2eWjiuBBtyCQzTKaczH/5+FdQ6kpE65yAXrR0/ut17B3ZVYr//dxPrtmO/A1jsaRcjp/Xyss19miOCZ+Ee4jNptuPFHZCVqNtoLcSnrMv2OqWDAsCZR7bHHRa49eJvsIiqqAhQkdXJUZt+hcoPaqVFq6UkvZeHk7PB5JIDfjDfV7wCLFLBST2uI9ByRH/fek3zHc1C6KISwE9BVWjtWLkCD+d9pGj8Q6i2B6qdYPKe74riKICcB+OkQyHzzrs2dWCJRrAabfi22+NTewB3oY98lmrhDjp6qCYpSMFpJRMTapGVsMIgtvk+VZ6R/v2cTumUHcYQyMeklCejCZ86Z9kh/TzNXMLwVYTEWhC6kWn2fg+Bh3tUwhTGnG98blr7iS+7qd1GQ3M+D2zi1ndd0aAhWOsTz7cnlLzipQC4Y0np3AejboWWmz2TDHs8KW5VfbYqcygJr3cTvCuvmKNlwX2PI7EBwMqi/UyODYgGn197Yy0qE0YM9V7vVilE+ZKFy17Sjpe7kHQUsNJ1VjHxoMA3PjVt056PzqxvfnABAIWEinSE7D/qVe+WZdvZIbVJWyr2RTW2dw/FD+3i9XD2tB2gb8vOgDZmVEWnq3P8iI572rjieaFBfG/F+ZeyU5fVvC69NwSUWV5h7bc50E9e2BP7lmxC4blZqqo9g1oh3ZCkHSqO0XKH5KKUMqtlRvrT25LC2w0g2Lgal9ED0/dvMkavH57ix39UE02v92CWsQgNXUygTiC7mf7qndgtdm5XV9qqTiIbV4NnPlLgd+/LBo/5HNVqXGH6R6Mdv8j3lbh238Xs75mKild1lnvYUz9JORZ/FMXBpnx0JsZsF7VtZPNIpt6Sz8LJ/dtN7zexTxhbjzzUjCedbpt 3iP86IrD 1XUrftudrGZq9GwOTSqxIUll4Fnq4YBnPZ7hN7qji8/vEVJUtdUKD8o+v3WOqmHIi6+UGGzTJvTSj9LgvLM8FQoFrXj7ngcNU41IqZmENdf8aBoKkxMcn+T8eKffjUoSnG9HRxqIMj3vHUebhf0Unvta6a1GxER7jkuwzdJCJPggoNkQZoX9CmNGqX/OMiyJIeIqQ4qViYgSQ6C7sH8BXN4gFacVXmLFrBNX7jgKe4uQfRoTGO/U/WQlh5fzK0HCBSxNK6Ir1tNyfpijS1hkwNZBgDVhmF9iHjRmhyPGkOtGerp4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000030, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 8 Aug 2024 23:13:27 +0800 Shiyang Ruan wrote: > CXL device can find&report memory problems, even before MCE is detected > by CPU. AFAIK, the current kernel only traces POISON error event > from FW-First/OS-First path, but it doesn't handle them, neither > notify processes who are using the POISON page like MCE does. > > Thus, user have to read logs from trace and find out which device > reported the error and which applications are affected. That is not > an easy work and cannot be handled in time. These are async reports, so I'm not sure what 'in time' really means here. If we get synchronous poison from a processor access it will be handled via traditional means (MCE, ARM SEA etc) Whether to handle async error reports (typically from scrub or because the memory device received poison from someone else) the same way should perhaps be a policy decision. It should match what we do for firmware first async reports though (any policy controls make sense for both). An example of this would be that an host OS might attempt a polite close of an application might attempt a polite if we know there is poison somewhere in a dataset it has access to. If that poison is never seen synchronously (because that data is not read) then it my close successfully rather than being killed. If it's injected poison and we didn't see it synchronously we might well not want to kill anything. > Thus, it is needed to add > the feature to make the work done automatically and quickly. Once CXL > device reports the POISON error (via FW-First/OS-First), kernel > handles it immediately, similar to the flow when a MCE is triggered. > > The current call trace of error reporting&handling looks like this: > ``` > 1. MCE (interrupt #18, while CPU consuming POISON) > -> do_machine_check() > -> mce_log() > -> notify chain (x86_mce_decoder_chain) > -> memory_failure() > > 2.a FW-First (optional, CXL device proactively find&report) > -> CXL device -> Firmware > -> OS: ACPI->APEI->GHES->CPER -> CXL driver -> trace > \-> memory_failure() > ^----- ADD > 2.b OS-First (optional, CXL device proactively find&report) > -> CXL device -> MSI > -> OS: CXL driver -> trace > \-> memory_failure() > ^------------------------------- ADD > ``` > This patch adds calling memory_failure() while CXL device reporting > error is received, marked as "ADD" in figure above. Typo in patch title. handling I've also dropped qemu-devel as this doesn't have anything to do with qemu. > > Signed-off-by: Shiyang Ruan Experienced RAS folk in the CC, how do you want this to work for asynchoronous memory errors on CXL devices?