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 8FD96C433F5 for ; Tue, 26 Apr 2022 19:51:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA09C6B0073; Tue, 26 Apr 2022 15:51:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E4F0F6B0074; Tue, 26 Apr 2022 15:51:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFD676B0075; Tue, 26 Apr 2022 15:51:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id C001A6B0073 for ; Tue, 26 Apr 2022 15:51:09 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 970BE2030F for ; Tue, 26 Apr 2022 19:51:09 +0000 (UTC) X-FDA: 79400073858.13.FC3C07C Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by imf13.hostedemail.com (Postfix) with ESMTP id B68FF2004E for ; Tue, 26 Apr 2022 19:51:02 +0000 (UTC) Received: by mail-ua1-f41.google.com with SMTP id 63so7230850uaw.10 for ; Tue, 26 Apr 2022 12:51:08 -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=tbJvwn4i2pJSPkHfFXHxQjr/2BdJtuP7PR7oVq6q6z0=; b=Rt2dv+RcJKRLogRQ9ROONsA2rDEmjabnGwlb7U0jqWSoviJJKOGCN9jhXTaH942vu8 RgEhhtVg6QyXzGoknclWoN1RjoZXP6iUVvbwwFkBv0UbFULUJSmcfuYZHIFzKeNdTPHN tw4OIo0XIhbaRFTniFm76JwhOuzvCZ1HAIYUt2Lv6M65ypIxTtcV+ziKPBEK0ZXJ9b7w g5UrYLahLXK9sUHK5tGe4Z9yASYds4aYCJebZeZQXslv1g1/UgN+AOqLeS04Q8BHpyWv 49NodTb65OvJv0BOfKOoVUbTyPZy90QI5QSc+cDci4MSxjULpLwz+tbHJmLjGiK705TV CNrA== 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=tbJvwn4i2pJSPkHfFXHxQjr/2BdJtuP7PR7oVq6q6z0=; b=VhBYy9+HNncVLhoCIkhlaMmEey1+T/X/goaYgsx4ZU/ce4P6MBABS8hwz9kAysvAbv uO+9qf9NTn6PtppFAeLCKzmVzgQrhOkSoG0DurSmHjgSinEdu7lf4m9cKKHpGu08uyjL JEz+nDoWIk6AB7eJ9phmnQ+sZlMGcTsw2nRwj+Kpw/RTzpN3qMWQcTkJU7lWXHHBpdkW cAjR7tAMN2YrqaEkZx6GsoKjbhYYrYUWlZbXTQIkPqki2mnHtxnP5xVFYDH9Hi1TOaaR VVPb8vsYcD7B1CffB6/7mordlvgbv94m4MZjro8/+Ygdkjro/dQ4HDsOTn2tj/CCFZ+a ivOw== X-Gm-Message-State: AOAM533EUmdv5ZIwlxGTidtTYpxlRuHjHZA5RghFT/GlEdoW0OywXh3o pm5Ln++dRVDDJo6UkdslhwGNjd4pOm20w0vqCEXe2Q== X-Google-Smtp-Source: ABdhPJzztgObrn09fFHsrw+p7bVmMuyFyhnKq78DFSs37+MVBCZ65W+0vfVqTvIXEw1BNh8DFcIymwKWxHWaeTeBTWw= X-Received: by 2002:ab0:76ce:0:b0:35c:c69e:717a with SMTP id w14-20020ab076ce000000b0035cc69e717amr7272086uaq.117.1651002668085; Tue, 26 Apr 2022 12:51:08 -0700 (PDT) MIME-Version: 1.0 References: <20220425163451.3818838-1-juew@google.com> <5a7f00e3-311d-b5ca-4249-7f50f8712559@intel.com> In-Reply-To: From: Jue Wang Date: Tue, 26 Apr 2022 12:50:56 -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: B68FF2004E X-Stat-Signature: py1zn4axdxhpj1u1t5kzfhpe94g6jto9 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Rt2dv+Rc; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of juew@google.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=juew@google.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1651002662-732779 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000457, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Apr 26, 2022 at 12:36 PM Dave Hansen wrote: > > On 4/26/22 12:23, Jue Wang wrote: > > On Tue, Apr 26, 2022 at 11:18 AM Dave Hansen wrote: > >> What if you're in a normal (non-TDX) guest and some of the physical > >> address space has been ballooned away? > > > > Accessing to memory that gets ballooned away will cause extra EPT > > violations and have the memory faulted in on the host side, which is > > transparent to the guest. > > Yeah, but it completely subverts the whole purpose of ballooning. In > other words, this is for all intents and purposes also mutually > exclusive with ballooning. True. We haven't thought too much about the TDX/SEV-SNP use cases. For "normal" guests, the operating model is that it's sufficient for the scanning to happen just on the host side with the ability to inform / inject without interrupting execution the detected errors in "real" time via UCNA injection being added to KVM. > > >> What does the kernel do when userspace asks it to poke a non-"System > >> RAM" address? > > > > I expect the kernel should reject the request with -EINVAL. > > Right. Only the kernel has the knowledge of what can actually _be_ > scanned. So, why even bother exposing physical addresses to userspace? > Why is exposing the actual physical address any better than exposing a > cookie? Then the API needs some re-design, naively I can see it works this way: init_as_start_page(&cookie); while(cookie != END_SCAN) { ret = ioctl(, SCAN_SIZE, numa_id, &cookie /*input_output*/ ); /* Handle errors, poison detected etc. */ ... ... } > > > Just curious, what could be recommendations from Intel's perspective > > to make proactively poison detection work on TDX / SEV-SNP? > > I shouldn't speak for Intel as a whole, but I'll give you my personal > perspective. > > Right now, hosts can't scan TDX private memory, period. If you wanted > to do scanning, the guest has to do it or you have to kill the guest and > make the memory non-private. > > Going forward, guest memory scanning could be accomplished by allowing > the VMM to migrate guest pages. Let's say you want to scan page "A", > you could move A->B and B->A. That would certainly touch the page. > This would need to be implemented in the TDX module. > > Or, the TDX module could have a special call to just touch the page. > > It would probably also need more work in the TDX module to be able to > handle machine checks. I don't think the handling in there is very > robust today. > > It could also be implemented with some new VMM-side ISA which promises > to touch the physical memory, but doesn't return any data, ignores the > "TD bit" and doesn't do any integrity checking. Thanks for the suggestions, Dave. We will follow up offline with Google colleagues and look to bring this up to some RAS discussion venue with Intel.