Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp4243292rwi; Mon, 17 Oct 2022 03:42:53 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5DbkWNoyUfGHUr2tee3+J07Ib0lFwG+MIA0OM/FIqc/Vs8qY4A/9O4AD2trme9urPci1nD X-Received: by 2002:a05:6a00:1d26:b0:54e:8c81:9f64 with SMTP id a38-20020a056a001d2600b0054e8c819f64mr11933879pfx.58.1666003373298; Mon, 17 Oct 2022 03:42:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666003373; cv=none; d=google.com; s=arc-20160816; b=JCmL3gxf5QG2eEGpAqr7quUF8IzQYVwU3fDWi1m1//NT+pug5iF5QTINFnXnQq8XjF 3/3b9EGEeJmIhRmlpDm+HEyBCrcQa3kw3jj//W2qPb4s5szLGBVZ2UaC7RShfkLrwRim iXNqDmZ2EnpWSjqvfJaB4AbPEHB39CHzuFb6QijxU8Z3lfcyLO4LyEemvuYybimD0JLw Mygjn5cpOfMm2qHB2dNGJf9/mVNvz+GQGCmaliBgq99B8VXswcF+pA7Wm0w98rgqFL5z BmyBUDVzI0zRf+qHtyD01vQbyY41u485dDzwFcs0idLoQ+vMJEZ2gniWB5IedfczlKZ+ kJ+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=5nozSFDmTVpu8GTMuUa17TgcVMpawH1V5x78PIRZetg=; b=nDYG0jjNY0nixVEAUSVGqLXcYDLaoIIE2Xdsbh6fLJBvB1kZpKQoDX/APfg7l5abVe yqUv2BLk+Ay9J6pA0d/UEpSgr8xKaZgC9pAyK2m44iV0jJcit2CAImSgo5OIOgcW9QTl W7hx0LvbbK1naXwflIR+ZXkEncqbTbkau5ykpRTfMGYzLfruGMWQRyPoUOTVTy2hikt3 BgPR2k47FGOmV64iEKyIjLWV6Pgax0U0WtP9FpACZP41zXBlgZv7OZeoxIzwOzjmvdP4 SQpcrmSiiwa/SWlNfeGNSScC/VI5fFF27RB4szJVf+cOrX1jYTKV4COlIFg2q8BJy7px lwJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=SDSplUZ2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s14-20020a17090302ce00b0016c44b7c8c5si10942304plk.11.2022.10.17.03.42.40; Mon, 17 Oct 2022 03:42:53 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=SDSplUZ2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230323AbiJQKcF (ORCPT + 99 others); Mon, 17 Oct 2022 06:32:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230298AbiJQKcC (ORCPT ); Mon, 17 Oct 2022 06:32:02 -0400 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01D526052D for ; Mon, 17 Oct 2022 03:31:57 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id be13so1171826lfb.4 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=CiJqy/DhUMxxswLuZpRwk09VW/qLeBPjkUin2RekPO+jeujZ40u6XDfPxGtq8AixGe fnxLm/gJj/xWEl4na3+867Zw3EpiJE3QlZXargKpBcU9y0ONPtkzRH+qaKo4ZYcTeb6z OF8cRC6aPxiOP/wWo8q7pL+NLtxs/Fx86VHn4NlHehhtv8OQB5yk2xd8T4xD+9eW9mZc ZNbqJw2K+J3/5yivP9b/iz8c90B7TnSfo3pkqZ5QnWYew2awLNRnl3PyX8VHrcolvxjT 5le5wQU2N00K4Y5eaegn5giFsnk67ghSzBSfD5bL1+92xox1TPLRBxu79SUXeXAt3LvX SseA== X-Gm-Message-State: ACrzQf1c47Y0MzFhSuwXqGbuXyTU/viHPsTeDaj6zU1XZGkNqUVQSa4V Ewo8QiQdVg1HzWPgoj7CXSI3dKssEMO/upmcBv92kQ== 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" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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: X-Mailing-List: linux-kernel@vger.kernel.org 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