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 DDA7FC433EF for ; Tue, 7 Jun 2022 07:01:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 46A326B0074; Tue, 7 Jun 2022 03:01:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F2716B0075; Tue, 7 Jun 2022 03:01:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 292CB6B0078; Tue, 7 Jun 2022 03:01:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 137FE6B0074 for ; Tue, 7 Jun 2022 03:01:28 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E56FD683 for ; Tue, 7 Jun 2022 07:01:27 +0000 (UTC) X-FDA: 79550543814.14.2D76D3C Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf15.hostedemail.com (Postfix) with ESMTP id B7443A0054 for ; Tue, 7 Jun 2022 07:00:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654585284; x=1686121284; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=ZV74rA8Yj9vsewf5ZR+zBoOmFi7pomIO9JTPNnhNKN8=; b=Ke+8LDaVc/iGWbG5wUr1RrLNWml8pAwzSZU4LAb4BZ5/H3U7zBuBuVZp K8sbcbeMEDnQl1nn/DcLxoUkZnOAI7YwBVUBlAYsFoJVibRVgNroE6Db0 Fx3Zjl70G26bE1PmOD51TkmSfu3N15v+JS0jTr2lU09LkVBv/vlaEhFPx McnW+o7/fojvdeuC7KBVjrTNQ11owpf1chgel0giLm9AJByRuSE/8fF15 SPJwels3IzPlvK7edxtKrKsEUWZD3wDFP0thKGyjil2LYx66RFQdUzdSJ iJbYY6y1jVg0N3iz/TJHvm0Kt7j51Sj1RozzDQONJF8UihONQhtxVzWHF w==; X-IronPort-AV: E=McAfee;i="6400,9594,10370"; a="259363975" X-IronPort-AV: E=Sophos;i="5.91,283,1647327600"; d="scan'208";a="259363975" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2022 00:01:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,283,1647327600"; d="scan'208";a="579485634" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.192.101]) by orsmga007.jf.intel.com with ESMTP; 07 Jun 2022 00:01:13 -0700 Date: Tue, 7 Jun 2022 14:57:49 +0800 From: Chao Peng To: Vishal Annapurve Cc: 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 , Sean Christopherson , 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 , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Yu Zhang , "Kirill A . Shutemov" , Andy Lutomirski , Jun Nakajima , dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com Subject: Re: [PATCH v6 0/8] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: <20220607065749.GA1513445@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220519153713.819591-1-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B7443A0054 X-Stat-Signature: 997wem3yhua4my1nhhjzbxdpebm3nean X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Ke+8LDaV; spf=none (imf15.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam08 X-HE-Tag: 1654585257-482621 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: On Mon, Jun 06, 2022 at 01:09:50PM -0700, Vishal Annapurve wrote: > > > > Private memory map/unmap and conversion > > --------------------------------------- > > Userspace's map/unmap operations are done by fallocate() ioctl on the > > backing store fd. > > - map: default fallocate() with mode=0. > > - unmap: fallocate() with FALLOC_FL_PUNCH_HOLE. > > The map/unmap will trigger above memfile_notifier_ops to let KVM map/unmap > > secondary MMU page tables. > > > .... > > QEMU: https://github.com/chao-p/qemu/tree/privmem-v6 > > > > An example QEMU command line for TDX test: > > -object tdx-guest,id=tdx \ > > -object memory-backend-memfd-private,id=ram1,size=2G \ > > -machine q35,kvm-type=tdx,pic=no,kernel_irqchip=split,memory-encryption=tdx,memory-backend=ram1 > > > > There should be more discussion around double allocation scenarios > when using the private fd approach. A malicious guest or buggy > userspace VMM can cause physical memory getting allocated for both > shared (memory accessible from host) and private fds backing the guest > memory. > Userspace VMM will need to unback the shared guest memory while > handling the conversion from shared to private in order to prevent > double allocation even with malicious guests or bugs in userspace VMM. I don't know how malicious guest can cause that. The initial design of this serie is to put the private/shared memory into two different address spaces and gives usersapce VMM the flexibility to convert between the two. It can choose respect the guest conversion request or not. It's possible for a usrspace VMM to cause double allocation if it fails to call the unback operation during the conversion, this may be a bug or not. Double allocation may not be a wrong thing, even in conception. At least TDX allows you to use half shared half private in guest, means both shared/private can be effective. Unbacking the memory is just the current QEMU implementation choice. Chao > > Options to unback shared guest memory seem to be: > 1) madvise(.., MADV_DONTNEED/MADV_REMOVE) - This option won't stop > kernel from backing the shared memory on subsequent write accesses > 2) fallocate(..., FALLOC_FL_PUNCH_HOLE...) - For file backed shared > guest memory, this option still is similar to madvice since this would > still allow shared memory to get backed on write accesses > 3) munmap - This would give away the contiguous virtual memory region > reservation with holes in the guest backing memory, which might make > guest memory management difficult. > 4) mprotect(... PROT_NONE) - This would keep the virtual memory > address range backing the guest memory preserved > > ram_block_discard_range_fd from reference implementation: > https://github.com/chao-p/qemu/tree/privmem-v6 seems to be relying on > fallocate/madvise. > > Any thoughts/suggestions around better ways to unback the shared > memory in order to avoid double allocation scenarios? > > Regards, > Vishal