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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47A9AC4332F for ; Mon, 17 Oct 2022 10:32:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230291AbiJQKcG (ORCPT ); Mon, 17 Oct 2022 06:32:06 -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-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" 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