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 35FCEC433FE for ; Mon, 17 Oct 2022 10:31:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D0916B0072; Mon, 17 Oct 2022 06:31:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 759236B0074; Mon, 17 Oct 2022 06:31:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AB516B0075; Mon, 17 Oct 2022 06:31:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4255C6B0072 for ; Mon, 17 Oct 2022 06:31:58 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E65581A0A3D for ; Mon, 17 Oct 2022 10:31:57 +0000 (UTC) X-FDA: 80030075874.17.C0DA43D Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf05.hostedemail.com (Postfix) with ESMTP id 72C47100030 for ; Mon, 17 Oct 2022 10:31:57 +0000 (UTC) Received: by mail-lf1-f52.google.com with SMTP id bu25so16848539lfb.3 for ; Mon, 17 Oct 2022 03:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5nozSFDmTVpu8GTMuUa17TgcVMpawH1V5x78PIRZetg=; b=SDSplUZ2VPkr2D1rPark9w6rINsj4QsGj8mIaHHj3cG7qqYj2xeg5bRcHWiAiCGNxn GsUn6i3U2OjLAFYiVGFUliiR7Eg727DK3wDSXfnbZMZbfbIZ31+HdQCxkX49ygkx2h2T JvvJpr3zkIRAU4V1EE328YM6hb7KitEqUGTlUdtUSKdTXZdHKruA7oQebxjBvB7yCdng 14amkvXgB/TlF3oG6EUoWuZ8TnSYQkSfag7jNPXgHEtx3NHXccP4GhcHXIeI1JTCLuLR Ff1yL/Q300jH2Amjcw85DuxVyH90T6VnZoMTJKObTmi2YSvh5JYckhqKh2RO00z96P+I iG8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5nozSFDmTVpu8GTMuUa17TgcVMpawH1V5x78PIRZetg=; b=1INS2uOyzOr8Dfvf8oZ/P3Qjq71yp6i3UPlZvXlNMuKVemXSKXYfmo1PfQ3/A6rIuq lDu3gIFVKniEsez3faWMIwpWLOTVLYqynhrFG1HbrXDVo1HWqPya1HK6y3pHijaSVDUX QsQ2t3onJUH0gF3JwGMukYpdPCo0ElzHSVd17VtlsYpQfUfWdYYw8CcsJKSrXGXAPYhr NnAL4gq7YzReujflteNGpX9d/BRo8clvx+Uz9FW35SaY1siGwO570Q6HlkZvB6HyHNTo jLAAS6albxDA7ZwBD/TiO2kUIp7+ntZ4J61B32qhWQImlJ3IUp8GcGeondYenQz1mcDs wwTA== X-Gm-Message-State: ACrzQf2YagUCI70pLq3cv18XhO1PURY8gTIDEWiOcr2PE3qKHZeidBLl rITHyVqY9FzXzPql9Ano9OFeMK2fojn6vsKOIR9QmA== X-Google-Smtp-Source: AMsMyM5QQdeoCZqf4USHrTYZuLKFaoT483vufBzxBArWmR3pEEZFNUg/KtF5cabXdDzXtcRyF9bfuHIHJTBpaJKALKA= X-Received: by 2002:a05:6512:4cb:b0:4a2:25b6:9e73 with SMTP id w11-20020a05651204cb00b004a225b69e73mr3967251lfq.30.1666002715568; Mon, 17 Oct 2022 03:31:55 -0700 (PDT) MIME-Version: 1.0 References: <20220915142913.2213336-1-chao.p.peng@linux.intel.com> <20220915142913.2213336-2-chao.p.peng@linux.intel.com> <20220926142330.GC2658254@chaop.bj.intel.com> <20221013133457.GA3263142@chaop.bj.intel.com> In-Reply-To: <20221013133457.GA3263142@chaop.bj.intel.com> From: Fuad Tabba Date: Mon, 17 Oct 2022 11:31:19 +0100 Message-ID: Subject: Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd To: Chao Peng Cc: Sean Christopherson , David Hildenbrand , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com, Will Deacon , Marc Zyngier Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666002717; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5nozSFDmTVpu8GTMuUa17TgcVMpawH1V5x78PIRZetg=; b=Qeg7G+41Ak6nP0rbzp67jXDkZP29rsLt1PvAfhqxQhRX7+sb4CduiPih/fFwYC3s/zXDP3 WrvBnNuPrv5o2w1NEVbfMGgG+NZlg11Y+g9TTr0lw9YUTn+FtvYGnpOkWr6YC9Tczn2k3F ElOXgGXpb9TDj/RAd2PsumMEOwxnvfU= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=SDSplUZ2; spf=pass (imf05.hostedemail.com: domain of tabba@google.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666002717; a=rsa-sha256; cv=none; b=XWEB2clpLUL98N3+82Uxz4jT7uLd54F8jfmuWqWbHyNMMUq1JivnaoXdiq4xfsH2lbr+IT +AjAzOGJqhY0GKYt3vFwQox7Yo5BWDQheP+jn5KYvu9SDi97+ec65WtHiK9hxWmtIkL6xc CIohE2g/4kjB7xgOj0KX5aW9xgOweV0= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 72C47100030 X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=SDSplUZ2; spf=pass (imf05.hostedemail.com: domain of tabba@google.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: ojp9weycycjjchpf7ptzated8orw7fjc X-HE-Tag: 1666002717-247556 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, > > > > Actually, for pKVM, there is no need for the guest memory to be > > GUP'able at all if we use the new inaccessible_get_pfn(). > > If pKVM can use inaccessible_get_pfn() to get pfn and can avoid GUP (I > think that is the major concern?), do you see any other gap from > existing API? Actually for this part no, there aren't any gaps and inaccessible_get_pfn() is sufficient. > > This of > > course goes back to what I'd mentioned before in v7; it seems that > > representing the memslot memory as a file descriptor should be > > orthogonal to whether the memory is shared or private, rather than a > > private_fd for private memory and the userspace_addr for shared > > memory. The host can then map or unmap the shared/private memory using > > the fd, which allows it more freedom in even choosing to unmap shared > > memory when not needed, for example. > > Using both private_fd and userspace_addr is only needed in TDX and other > confidential computing scenarios, pKVM may only use private_fd if the fd > can also be mmaped as a whole to userspace as Sean suggested. That does work in practice, for now at least, and is what I do in my current port. However, the naming and how the API is defined as implied by the name and the documentation. By calling the field private_fd, it does imply that it should not be mapped, which is also what api.rst says in PATCH v8 5/8. My worry is that in that case pKVM would be mis/ab-using this interface, and that future changes could cause unforeseen issues for pKVM. Maybe renaming this to something like "guest_fp", and specifying in the documentation that it can be restricted, e.g., instead of "the content of the private memory is invisible to userspace" something along the lines of "the content of the guest memory may be restricted to userspace". What do you think? Cheers, /fuad > > Thanks, > Chao > > > > Cheers, > > /fuad