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 4023BCD54AF for ; Tue, 19 Sep 2023 09:01:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BDBFE6B04DD; Tue, 19 Sep 2023 05:01:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B8BAD6B04DE; Tue, 19 Sep 2023 05:01:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A2BF96B04DF; Tue, 19 Sep 2023 05:01:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8FFAD6B04DD for ; Tue, 19 Sep 2023 05:01:51 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 610CF80C13 for ; Tue, 19 Sep 2023 09:01:51 +0000 (UTC) X-FDA: 81252754422.20.F1CB44E Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.93]) by imf26.hostedemail.com (Postfix) with ESMTP id C419814002A for ; Tue, 19 Sep 2023 09:01:48 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SEv6rbhc; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf26.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=binbin.wu@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695114109; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kHl8VDBX2EKUMZ4TCh89Lg3iqR6foMygsD2eAJAz4EE=; b=rVc7vpBrRDhdbDA2apqnWJGwg0LCfSTUeZN4w7br3Yua6fvWgPIRWBE3SuUohDDMFYzfCg d0CRxnb6arm2yO2fuT7PfyBoR8FyuYiNFt009m7gQ3GJjAs63J6f+sJ1U8VZ2y/DKhUrrg 4h9Fu8GOdahDQA59vVAUEm6ISo3+BIM= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SEv6rbhc; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf26.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=binbin.wu@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695114109; a=rsa-sha256; cv=none; b=awS0dNOFMyf71JKJr9C1t8lHElHqUQQBVe+p8XuP2qt8meagCxTf44lacRNpvJ4qYBtMWf GcUjXD5j5C3YtVu0Qm1PmT7o2YHRwcKGnTkwGTlFc+EIw0gwXjkcozb2qZkgYw9JzkOBnH tUDpD9olaw4x4wnbIm0G/U9aPE453oo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695114108; x=1726650108; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=3lbpMHnCnN4tgBMsnlxIOe9ua6EYGffh/u6hevJylxY=; b=SEv6rbhcAG8Brikv8KxJ0iQqqHg8DpUiAaNs2NfGenCq9A8bNsfHsqOn 1ZdP+JZplJJalD33nSs/kZOqOBBD8MM7rSCvpNUB5aF+SoCpiSAEB1WWw Po/wTwi0+8idSbCLrB6wiqfT5vA2PB11nF/c9fQfjLAlGnyGmOwGD/dmO YSf81UZ7oFrzNhOeiSr0zH5pDk10Hn3XPvP5ZzyGyEnPVMNgkWvItHiGX r+oihA0xvHZhdqaDCXXZnBu7uN741b++en1OTt1h3oZxNUDUJBqhGThHb zLPyIHzCI1l/ckkx2RbKOxocPk6DBUYn9r51JpbsfpI0zzxnl/zJB5zVm Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10837"; a="377201140" X-IronPort-AV: E=Sophos;i="6.02,159,1688454000"; d="scan'208";a="377201140" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2023 02:01:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10837"; a="695833326" X-IronPort-AV: E=Sophos;i="6.02,159,1688454000"; d="scan'208";a="695833326" Received: from binbinwu-mobl.ccr.corp.intel.com (HELO [10.238.8.84]) ([10.238.8.84]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2023 02:01:36 -0700 Message-ID: Date: Tue, 19 Sep 2023 17:01:31 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [RFC PATCH v12 14/33] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory To: Sean Christopherson Cc: kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-15-seanjc@google.com> From: Binbin Wu In-Reply-To: <20230914015531.1419405-15-seanjc@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: hfzd7pua7g9zyhztwdzdazmamj8z4mxr X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C419814002A X-HE-Tag: 1695114108-66739 X-HE-Meta: U2FsdGVkX19l7gIHR+YkLzyNUCbozzC3kyhBniyhQeTFca/Ey1iOoNVAkMqhYCMGke6/0/sTJHtAj0W3nkB3GEyXew3lkqgFgBwwFbmatRoG+47Rh+ykypoHC7C6Fi65oCJM81PGfT6MXHNkuuz8xIZsZczQl2Ocd2hVSNplP/jjMD+IufNOo3uR0SP1DDg4optxP+NnZInQg7ZEbVnXJyVxnH0lK0/4FqDqohqCrvNtNnVNPr6GwFYEvxdNxloGOwSM272hedPkFxvggcugQSWeTt69t090k55yrx1EHZ/7TPcDM1SFwy9GmjrQcrBsLKX76VbYTWQSGfpRJ+XRuMOte3gdJowFP8UhQYH+vlao28mGJh5Ro/HZP6QaJbjVNGyIxNNYLEyRcaLv6jlA8oCr6q4p1ZXJZTisoy/ZfztX+Ios6/xLXB//o7XdZ1raK8BJMvk8/NHTqxW7N+DY8XIk+HUn5Z3IzNMMp22i1vr7Z9vnNHYGxaFBXs9DpSG/DwGr8/wkwd2eIc6merhqaB9GjdXupkKvmJQ9sSl7MYgxcT73eNvNCCwZGwoHSevIZ5qtsGF3viu/drJ4zpY04Iw4U+x8F/e2Grhy6T2RkgsaJIhbGa1Ma94fzmJo8wpx3MxpZITvjUQ5VMM4tCIKwZSUIwBD4c+SPTW9DQX5vT3qxXFltd23Yn1iQnNjyqNtpUJc1W6IN7qWtnFgNtUkkp5vuDLv94DUc6ahehUFg9MZsKqmSu9d2Wu79bsjR8H0Wkp4/rgMatblrMXSBsO4cSPsTxhrVJinHjvQRM758D4tqNR8VMsmnVPRngruy5nJCydDbjW7JYcth6Cd4uYKfogzekEBd5t9VEtHvHN4r76T4q4vR74PfDA0wug6mdYtJP3sYIlXzzLHGavr9apNeeZUdXwl1yRRnH4MF5qQvfOh+YvakyQ4qL8N+r+j7LWNjyusiTg6rG1JrUeTOZ1 EUEhOtN4 tXKhHTV+a+EhfNv9Wsxhnii3BrI/4ojythD7uiLBJ3gBHe46j4Ov7IlBiiMk2Fr5eTEGrMWckp34jqwj4yX9UXlRApIbDa5alW3RQPiNIAUA3Ig9jnA+qBMGv7Y2VD+6GAqPkHX4mWQr26pIZbGWwi6GYLvwl0nT8mjGQ6Xd5FF1v4R7C1Q+IZ29fixBoNBCnepdVn3ZKAPUDmVn8MbZ0kbijLaqWkwHaRrGt3h4L27WoDunmE+0tiduQGw== 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 9/14/2023 9:55 AM, Sean Christopherson wrote: [...] > + > +static void kvm_gmem_invalidate_begin(struct kvm_gmem *gmem, pgoff_t start, > + pgoff_t end) > +{ > + struct kvm_memory_slot *slot; > + struct kvm *kvm = gmem->kvm; > + unsigned long index; > + bool flush = false; > + > + KVM_MMU_LOCK(kvm); > + > + kvm_mmu_invalidate_begin(kvm); > + > + xa_for_each_range(&gmem->bindings, index, slot, start, end - 1) { > + pgoff_t pgoff = slot->gmem.pgoff; > + > + struct kvm_gfn_range gfn_range = { > + .start = slot->base_gfn + max(pgoff, start) - pgoff, > + .end = slot->base_gfn + min(pgoff + slot->npages, end) - pgoff, > + .slot = slot, > + .may_block = true, > + }; > + > + flush |= kvm_mmu_unmap_gfn_range(kvm, &gfn_range); > + } > + > + if (flush) > + kvm_flush_remote_tlbs(kvm); > + > + KVM_MMU_UNLOCK(kvm); > +} > + > +static void kvm_gmem_invalidate_end(struct kvm_gmem *gmem, pgoff_t start, > + pgoff_t end) > +{ > + struct kvm *kvm = gmem->kvm; > + > + KVM_MMU_LOCK(kvm); > + if (xa_find(&gmem->bindings, &start, end - 1, XA_PRESENT)) > + kvm_mmu_invalidate_end(kvm); kvm_mmu_invalidate_begin() is called unconditionally in kvm_gmem_invalidate_begin(), but kvm_mmu_invalidate_end() is not here. This makes the kvm_gmem_invalidate_{begin, end}() calls asymmetric. > + KVM_MMU_UNLOCK(kvm); > +} > + > +static long kvm_gmem_punch_hole(struct inode *inode, loff_t offset, loff_t len) > +{ > + struct list_head *gmem_list = &inode->i_mapping->private_list; > + pgoff_t start = offset >> PAGE_SHIFT; > + pgoff_t end = (offset + len) >> PAGE_SHIFT; > + struct kvm_gmem *gmem; > + > + /* > + * Bindings must stable across invalidation to ensure the start+end > + * are balanced. > + */ > + filemap_invalidate_lock(inode->i_mapping); > + > + list_for_each_entry(gmem, gmem_list, entry) { > + kvm_gmem_invalidate_begin(gmem, start, end); > + kvm_gmem_invalidate_end(gmem, start, end); > + } Why to loop for each gmem in gmem_list here? IIUIC, offset is the offset according to the inode, it is only meaningful to the inode passed in, i.e, it is only meaningful to the gmem binding with the inode, not others. > + > + filemap_invalidate_unlock(inode->i_mapping); > + > + return 0; > +} > + [...]