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 A1D56EB64D7 for ; Wed, 21 Jun 2023 09:01:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E94DD8D0002; Wed, 21 Jun 2023 05:01:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1BA38D0001; Wed, 21 Jun 2023 05:01:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBD1E8D0002; Wed, 21 Jun 2023 05:01:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B6A4D8D0001 for ; Wed, 21 Jun 2023 05:01:30 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 910871A088B for ; Wed, 21 Jun 2023 09:01:30 +0000 (UTC) X-FDA: 80926161540.26.1764E0A Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by imf13.hostedemail.com (Postfix) with ESMTP id A085F2002B for ; Wed, 21 Jun 2023 09:01:28 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=YAkAPnxt; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of vannapurve@google.com designates 209.85.219.51 as permitted sender) smtp.mailfrom=vannapurve@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687338088; 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=GggaCXOFg4z+F5xlvFzI/hjEnVVezaR8FCxhsY4X+4k=; b=aB7UQwrnMfaHglV85rH9q2P6JBtKVDSdw71Zd4XTubmO6t99oNhb4RFdnwe8+Y9XxvHLZ5 PhqbUqI7weJczy4K3I9Tm0bnsj5lxelXsZSkwMVxbzSQXceBmpwmsOqd/eNA/FR4lCQ+8f YffDg3y1kxVxWGfOMUQg7/C6vbLhZOo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=YAkAPnxt; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of vannapurve@google.com designates 209.85.219.51 as permitted sender) smtp.mailfrom=vannapurve@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687338088; a=rsa-sha256; cv=none; b=R3yoEDbXU4kspKBRS43ykvO6D39McSdoZa1/93oleGattdgFdbdusJm88ujMSlNHzO7Inb CEHhQmAc/h0NtmOemoHbySMUNsRoctH0s4To8hI/ZKMIqzPQ6BfL53MDhTFs7lSIcN/HeS 8FFiO2iNhnh0WM1Z5wxDmF9cVMdd3QA= Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-62fe192f7d3so53055046d6.3 for ; Wed, 21 Jun 2023 02:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687338087; x=1689930087; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GggaCXOFg4z+F5xlvFzI/hjEnVVezaR8FCxhsY4X+4k=; b=YAkAPnxt6pZOgcUU5gErX3sbI43Adc76e+9dsxfRuvvo+hzThnkDKhy0joF+qo8LKM HkRf3+n40noWJYMgW83bd7IvUDZ/poWHNY3Jx1Z0KKe+uvulO3QyNs4xo6HTDMH2hPXm mEyTVrzeHNyELzHfZu0pENPirl89gRQWJHsWmtgLETtVwCs3WFG3VOYxDKL6+/p0L57u Ed6oukufenkRQxhbsbLj97fBL8/GHe0TLHzpbnHYFmrrtWgSp8ZZC8fJiJiVaSIZwngJ fGzr6DoZWgbSFyEfbfo7ZEqzCzJckfia6djl5Sxaxenl3VRUwlMPCMrLTnNH2Z7mADxU oCWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687338087; x=1689930087; h=content-transfer-encoding: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=GggaCXOFg4z+F5xlvFzI/hjEnVVezaR8FCxhsY4X+4k=; b=iNnrZDPpXTWZcowSSf/ZPQ97SbH13Twd+GJr3BSueV3T1wDyuhZ9GnGlF1UHpqBQKc YwJvSRjI4sYzEEmhJoPLrNjVsdyCzVWGklvNkOT1GT48iCHhYSWAJkEFICm7fiyuBEr0 PikavcUxGDZbofzzkzonBVmNJrzXHN59WKyQJeuf0VZThgYsKsssXMLSqePqs5KthSw7 Tou1tGQdFzGppGDyDXhoStecR8RD6Hkjb6LN9ZCi8u5FWhvwvg66YHgy4aNVJMWTPOKv ZlxO6+KU07aK6jDdq1cRBlGJ56UejjFFNZEr732tZF/E9MUQmcqNAgcxm2z409DxLm/0 Zk1A== X-Gm-Message-State: AC+VfDx4HcuzwKmoBWq6WKVfaeVWZGfElzlxH+jdwG9JHSiu7Jp6P0TR rvcPvZjQfV8RtVpvu02Edn8eU3fIKuBvuFKV1cbTiA== X-Google-Smtp-Source: ACHHUZ67nqRlyPSAmJAdYAQRecAssNEK0bXaPkvdoVklsOrLI7I63am8sKR0bbgFoaWyaJf4gLP9WVi33cBGzMyYMr0= X-Received: by 2002:a05:6214:1c87:b0:628:8185:bd6e with SMTP id ib7-20020a0562141c8700b006288185bd6emr6847558qvb.5.1687338087414; Wed, 21 Jun 2023 02:01:27 -0700 (PDT) MIME-Version: 1.0 References: <20230616182815.GA7371@monkey> In-Reply-To: <20230616182815.GA7371@monkey> From: Vishal Annapurve Date: Wed, 21 Jun 2023 02:01:16 -0700 Message-ID: Subject: Re: [RFC PATCH 00/19] hugetlb support for KVM guest_mem To: Mike Kravetz Cc: Ackerley Tng , akpm@linux-foundation.org, muchun.song@linux.dev, pbonzini@redhat.com, seanjc@google.com, shuah@kernel.org, willy@infradead.org, brauner@kernel.org, chao.p.peng@linux.intel.com, coltonlewis@google.com, david@redhat.com, dhildenb@redhat.com, dmatlack@google.com, erdemaktas@google.com, hughd@google.com, isaku.yamahata@gmail.com, jarkko@kernel.org, jmattson@google.com, joro@8bytes.org, jthoughton@google.com, jun.nakajima@intel.com, kirill.shutemov@linux.intel.com, liam.merwick@oracle.com, mail@maciej.szmigiero.name, mhocko@suse.com, michael.roth@amd.com, qperret@google.com, rientjes@google.com, rppt@kernel.org, steven.price@arm.com, tabba@google.com, vbabka@suse.cz, vipinsh@google.com, vkuznets@redhat.com, wei.w.wang@intel.com, yu.c.zhang@linux.intel.com, kvm@vger.kernel.org, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, qemu-devel@nongnu.org, x86@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: phrp9ei5qawbr7khmuq5zrgncyshqmu6 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A085F2002B X-HE-Tag: 1687338088-522535 X-HE-Meta: U2FsdGVkX19TmN+XIH3bMEwR8dN51E3ZVem1OcpyFccXAKO5jlMkGLPRKoCP7iBPN7uSYDaB6Y0UqigG9LOcmgY2GHbMIp8GZqs7i4Erep5/jTIeWZm8WSe6bN6d1LwGoCY3CbbsAPJAnXqVyYsU147nnFF7YQ4+B9KhVioYaGBm1zWbrPVtsc6hfxzu1z6v927wpFdimOifCmdu9Vdv3LNHVxBzMr7wfpd7VAuR+yUqMWT1VS4LvofaNmq4bCGEzcCdVZFPMYFg50LqVhR5+phb44pSXOQXDzJWWK2+IPvV2U5WRa/qyfRWbTVPzkrEj5HwyszvjXiwIlU/W3AZudnMHLMj9CluXpRDueSRlWug96jUKu2/EAjzjFRag7BJNxjuRfHiwm9IpQHT+9tg8H0WLFXYajsHqslImhMpXil4T2HB1QoPLG5/hNLHIzTQnoQ8FrjT4HrX2asSP/7IjKhzlkPKdppGNj+jltg4O5AklJDyBQaxiBwhYDa+Mq5GXXhfs0bvAlYL3S6tbIgwJBqlxUJY6ABV9F38VCNX5pkkiRYK4FlcKxnibUXs+quXMWBgxg3GJ62wYtg8eOQ6hpz2NxjdwGso85rP4sXZ6z4ODIDJZVNrgkmNmEtWvXhqyfpc2Ykdx4eddbY42PIkVYj4hKBi22T3ncpjpzbTHKxBa5aSTCGTQG4ioV+9F/LFxxK8PwuuEVHEO6HJOpOcRCnxk72SCkpqtp8e2JRcEynPY8i2cZljex1CMIWWWCidqdaNOdrogFK8rk5GpCXRnDFAh6isLb9sIiplp0+z56Zy3vFcOT+ykL37/e4wTGqrhzRxJH9U+Jf5FZf0cZbnA7PKn58aZTdB2qQgLQ66dmll9/eA9blDBcYNIJGUWYebl/0HWKWwvdDIRhwNlRGVyAeY1HM539uiKGKG3Wl4Ja+lD6Uj8L8trXoJg7i6/Iq9Jgd0wclY7oiKCTVRzqD 5C/TGEsZ aPWaN+HHkb0sER8QXVmDs2z5d7+J9thDhHbmI2F/gP7mZrI3c2RVXqnxFcEt7KbDu6LaLlpyvYLH5TZuUroHKF53/4TqUrIY21nL/d/haHJcvUpkm4TKbBvZ/vYjRbA6XF87LlXvGvC4JcYQcwVoXm6ZPEio6Bc5xuM1L8wPLsXTB/ah3S4snO449AW6vhwcSa2puCmXhv9mLXWKB2eJfvuCekTaUJRsQhni33cVmVNRsHCfWcRvKoGFiZupTejkWH7FP0hgH5UMiQPLhSJAa0G256MsoDh04356bWIsVHAzn+yzq/3MhWTgkRxStJYmTBCps0aCYEoestfptSXvXO5H9B7EdEaau/8Zk8DH2rC8OoZgzIA8EiJcLZ/KqEEuhaukZ9fH6ZXPVYfwbeSSq4woIjN7cXDz+B9QKGIQarH/laeso80PL7QkOu3bYvFYARGDZjIdXd6Lv+hg= 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 Fri, Jun 16, 2023 at 11:28=E2=80=AFAM Mike Kravetz wrote: > > On 06/06/23 19:03, Ackerley Tng wrote: > > Hello, > > > > This patchset builds upon a soon-to-be-published WIP patchset that Sean > > published at https://github.com/sean-jc/linux/tree/x86/kvm_gmem_solo, m= entioned > > at [1]. > > > > The tree can be found at: > > https://github.com/googleprodkernel/linux-cc/tree/gmem-hugetlb-rfc-v1 > > > > In this patchset, hugetlb support for KVM's guest_mem (aka gmem) is int= roduced, > > allowing VM private memory (for confidential computing) to be backed by= hugetlb > > pages. > > > > guest_mem provides userspace with a handle, with which userspace can al= locate > > and deallocate memory for confidential VMs without mapping the memory i= nto > > userspace. > > Hello Ackerley, > > I am not sure if you are aware or, have been following the hugetlb HGM > discussion in this thread: > https://lore.kernel.org/linux-mm/20230306191944.GA15773@monkey/ > > There we are trying to decide if HGM should be added to hugetlb, or if > perhaps a new filesystem/driver/allocator should be created. The concern > is added complexity to hugetlb as well as core mm special casing. Note > that HGM is addressing issues faced by existing hugetlb users. > > Your proposal here suggests modifying hugetlb so that it can be used in > a new way (use case) by KVM's guest_mem. As such it really seems like > something that should be done in a separate filesystem/driver/allocator. > You will likely not get much support for modifying hugetlb. > > -- > Mike Kravetz > IIUC mm/hugetlb.c implements memory manager for Hugetlb pages and fd/hugetlbfs/inode.c implements the filesystem logic for hugetlbfs. This series implements a new filesystem with limited operations parallel to hugetlbfs filesystem but tries to reuse hugetlb memory manager. The effort here is to not add any new feature to hugetlb memory manager but clean it up so that it can be used by a new filesystem. guest_mem warrants a new filesystem since it supports limited operations on the underlying files but there is no additional restriction on underlying memory management. Though one could argue that memory management for guest_mem files can be a very simple one that goes inline with limited operations on the files. If this series were to go a separate way of implementing a new memory manager, one immediate requirement that might spring up, would be to convert memory from hugetlb managed memory to be managed by this newly introduced memory manager and vice a versa at runtime since there could be a mix of VMs on the same platform using guest_mem and hugetlb. Maybe this can be satisfied by having a separate global pool for reservation that's consumed by both, which would need more changes in my understanding. Using guest_mem for all the VMs by default would be a future work contingent on all existing usecases/requirements being satisfied. Regards, Vishal