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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 93ED7C433F5 for ; Tue, 23 Nov 2021 14:36:33 +0000 (UTC) Received: from localhost ([::1]:58686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mpWuO-0001v3-Ak for qemu-devel@archiver.kernel.org; Tue, 23 Nov 2021 09:36:32 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60078) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpWsl-0000i9-9Y for qemu-devel@nongnu.org; Tue, 23 Nov 2021 09:34:51 -0500 Received: from mga03.intel.com ([134.134.136.65]:42379) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpWsj-0003J2-4G for qemu-devel@nongnu.org; Tue, 23 Nov 2021 09:34:51 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10176"; a="234978986" X-IronPort-AV: E=Sophos;i="5.87,258,1631602800"; d="scan'208";a="234978986" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Nov 2021 06:34:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,257,1631602800"; d="scan'208";a="509430316" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.192.101]) by orsmga008.jf.intel.com with ESMTP; 23 Nov 2021 06:34:39 -0800 Date: Tue, 23 Nov 2021 22:33:53 +0800 From: Chao Peng To: Paolo Bonzini Subject: Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST Message-ID: <20211123143353.GD32088@chaop.bj.intel.com> References: <20211119134739.20218-1-chao.p.peng@linux.intel.com> <20211119134739.20218-2-chao.p.peng@linux.intel.com> <20211119151943.GH876299@ziepe.ca> <6de78894-8269-ea3a-b4ee-a5cc4dad827e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6de78894-8269-ea3a-b4ee-a5cc4dad827e@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) Received-SPF: none client-ip=134.134.136.65; envelope-from=chao.p.peng@linux.intel.com; helo=mga03.intel.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Chao Peng Cc: Wanpeng Li , jun.nakajima@intel.com, kvm@vger.kernel.org, David Hildenbrand , qemu-devel@nongnu.org, "J . Bruce Fields" , linux-mm@kvack.org, "H . Peter Anvin" , ak@linux.intel.com, Jonathan Corbet , Joerg Roedel , x86@kernel.org, Hugh Dickins , Jason Gunthorpe , Ingo Molnar , Borislav Petkov , luto@kernel.org, Thomas Gleixner , Vitaly Kuznetsov , Jim Mattson , dave.hansen@intel.com, Sean Christopherson , susie.li@intel.com, Jeff Layton , linux-kernel@vger.kernel.org, john.ji@intel.com, Yu Zhang , linux-fsdevel@vger.kernel.org, Andrew Morton , "Kirill A . Shutemov" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, Nov 23, 2021 at 10:06:02AM +0100, Paolo Bonzini wrote: > On 11/19/21 16:39, David Hildenbrand wrote: > > > If qmeu can put all the guest memory in a memfd and not map it, then > > > I'd also like to see that the IOMMU can use this interface too so we > > > can have VFIO working in this configuration. > > > > In QEMU we usually want to (and must) be able to access guest memory > > from user space, with the current design we wouldn't even be able to > > temporarily mmap it -- which makes sense for encrypted memory only. The > > corner case really is encrypted memory. So I don't think we'll see a > > broad use of this feature outside of encrypted VMs in QEMU. I might be > > wrong, most probably I am:) > > It's not _that_ crazy an idea, but it's going to be some work to teach KVM > that it has to kmap/kunmap around all memory accesses. > > I think it's great that memfd hooks are usable by more than one subsystem, > OTOH it's fair that whoever needs it does the work---and VFIO does not need > it for confidential VMs, yet, so it should be fine for now to have a single > user. > > On the other hand, as I commented already, the lack of locking in the > register/unregister functions has to be fixed even with a single user. > Another thing we can do already is change the guest_ops/guest_mem_ops to > something like memfd_falloc_notifier_ops/memfd_pfn_ops, and the > register/unregister functions to memfd_register/unregister_falloc_notifier. I'm satisified with this naming ;) > > Chao, can you also put this under a new CONFIG such as "bool MEMFD_OPS", and > select it from KVM? Yes, reasonable. > > Thanks, > > Paolo