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 4C957C433F5 for ; Tue, 26 Apr 2022 17:57:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D72C86B0073; Tue, 26 Apr 2022 13:57:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D21BF6B0074; Tue, 26 Apr 2022 13:57:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC4036B0075; Tue, 26 Apr 2022 13:57:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id AC5716B0073 for ; Tue, 26 Apr 2022 13:57:31 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7310E20E4F for ; Tue, 26 Apr 2022 17:57:31 +0000 (UTC) X-FDA: 79399787502.04.9986401 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf23.hostedemail.com (Postfix) with ESMTP id A775814004C for ; Tue, 26 Apr 2022 17:57:25 +0000 (UTC) Received: by mail-vs1-f48.google.com with SMTP id v139so8760240vsv.0 for ; Tue, 26 Apr 2022 10:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OGDcR/Uhyk2iwa2hGBzgqcxnc5i/8Zm7bmCutTRYvj8=; b=Ojp+R+onAN98Gndr6I1AN2OtdY9bvjlwKMJ2eE5JE7vTzuVH3YTTaRzeqZhDRgmVkB bMfQoKGtjHYP1LTaoCqnlwJWeQRiXanRkSgz9zGclFb8aQOmCP1epwwiJQJb2FmNgQXd cGfA+yM+HN0XbUsD7MpEioO3UH340qwbUsmPgAYJxLY6TraKf5UgISg9Yz1IZWf1yh1A UQy7dheTEyhkoTk/oKySj2I7YkM0wuMFAG3bxC3FkFL6fv1rsXX56ZvRAMKUIPieLBn6 NjzWroGyoFBEPK3VZHZKg+/b2CwPAHQUOaD5ruczNAuGmThglWgG5H9EcDWnZ+bCNvjL 14cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OGDcR/Uhyk2iwa2hGBzgqcxnc5i/8Zm7bmCutTRYvj8=; b=Ng8qZ52XgfSNQ1bhusYG3LluYuJ5cpJZkKsKEwYo8xfRseEuMlPkXoW4uS/PK8wy1E II18ybPA7/S/YZ7QzwggNwdDPBH06C2p0gXvzeYvIDBqp8sQ6Pn2IC4q/MaqfgnPViBQ sMkbCTSyuDzYUvoTOgA2fLtCFWL8k3eiEdOSe3inEOsNuispFuXiJHbSDz4hjJMUwRrb SWP/OUkeDWtvd9B9khWjwZxnRVnHusiJdHd4nIXPYg98GsWU6Gl4SkUqQ7aU0FzD2UoQ 8F6SXzJahULY7OESPbAdrd41D+H5Si/9GsTjTqUNl6u28GIvgp+6QrKjvtaJhutUX8+b Wvew== X-Gm-Message-State: AOAM532/mVJDcH7/fsMP7dLgi8/g6GhPQaBbNPR9xIuCQttntNVRWs8P HGuejqH5/btbXXPuexVNn+nLKUYAReK+xXNhjK5lHw== X-Google-Smtp-Source: ABdhPJxs7Vag7/TUU5vJQQylcsMl+Q6m0NE34IVdzXyNA/EjTh2HcfxvyvN+bOfEs9WNDPTvq9dsXxwtRb5WDj9ZaZc= X-Received: by 2002:a05:6102:9a:b0:32c:dca8:4912 with SMTP id t26-20020a056102009a00b0032cdca84912mr2818462vsp.13.1650995850002; Tue, 26 Apr 2022 10:57:30 -0700 (PDT) MIME-Version: 1.0 References: <20220425163451.3818838-1-juew@google.com> In-Reply-To: From: Jue Wang Date: Tue, 26 Apr 2022 10:57:18 -0700 Message-ID: Subject: Re: [RFC] Expose a memory poison detector ioctl to user space. To: Dave Hansen Cc: Naoya Horiguchi , Tony Luck , Dave Hansen , Jiaqi Yan , Greg Thelen , Mina Almasry , linux-mm@kvack.org, Sean Christopherson Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A775814004C X-Stat-Signature: gp978i8te6bgdcrtwwu4jsb7qxs3zdbm X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Ojp+R+on; spf=pass (imf23.hostedemail.com: domain of juew@google.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=juew@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam09 X-HE-Tag: 1650995845-185756 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Dave, Thanks for the reply, some comments inline. On Tue, Apr 26, 2022 at 8:40 AM Dave Hansen wrote: > > From your description, you have me mostly convinced that this is > something that needs to get fixed. The hardware patrol scrubber(s) > address the same basic problem, but don't seem to be flexible to your > specific needs. > > But, have hardware vendors been receptive at all to making the patrol > scrubbers more tunable? We have discussed the use case in detail with Intel. There are improvements in progress to address some of the issues like the signaling to avoid broadcasted MCEs. But fundamentally, the needed throughput is not quite compatible with the patrol scrubber's design purpose and arch. It's unclear at what generation of hardware this need may get addressed. Thus now, we look at software assisted approaches making use of the _whole_ CPU. > > On 4/25/22 09:34, Jue Wang wrote: > > /* Could stop and return after the 1st poison is detected */ > > #define MCESCAN_IOCTL_SCAN 0 > > > > struct SysramRegion { > > /* input */ > > uint64_t first_byte; /* first page-aligned physical address to scan */ > > uint64_t length; /* page-aligned length of memory region to scan */ > > /* output */ > > uint32_t poisoned; /* 1 - a poisoned page is found, 0 - otherwise */ > > uint32_t poisoned_pfn; /* PFN of the 1st detected poisoned page */ > > } > > So, the ioctl() caller has to know the physical address layout of the > system? This info is available from /proc/iomem and /proc/zoneinfo already supported / exposed by the kernel. > > While this is a good start at a conversation, I think you might want to > back up a bit. You alluded to a few requirements that you have, like: > > * Adjustable detector resource use based on system utilization > * Adjustable scan rate to ensure issues are found at a deterministic > rate > * Detector must be able to find errors in allocated, in-use memory > > What about SEV-SNP or TDX private memory? It might be unmapped *and* > limited in how it can be accessed. For instance, TDX hosts can't > practically read guest memory. SEV-SNP hosts have special page mapping > requirements; the cost can't create arbitrary mappings with arbitrary > mapping sizes. What would this ioctl() do if asked to scan a TDX guest > private page? > Thanks for raising the UPM case for SEV-SNP / TDX private memory. This is what we like to get more feedback and more experts' weigh-ins. Is reading private memory via kernel's direct mapping benign for SEV-SNP and TDX? If true, could this be a way to let SEV-SNP and TDX use cases benefit from this work while the user space / hypervisor mapping is still removed? Otherwise this feature should be defined as mutually exclusive with incompatible features. Even in that case, I believe SEV-SNP or TDX may still benefit from _reactive_ memory poison recovery if the MCE handling and CONFIG_MEMORY_FAILURE still function the same on uncorrectable error raised #MC. > Is doing it from userspace a strict requirement? > > Would the detector just read memory? > > Are there any other physical addresses which are RAM but should not have > the detector used on them? >