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 2E609C77B7F for ; Tue, 24 Jun 2025 17:50:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C0F16B00AE; Tue, 24 Jun 2025 13:50:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 570D96B00AF; Tue, 24 Jun 2025 13:50:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 439226B00B3; Tue, 24 Jun 2025 13:50:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2C6D06B00AE for ; Tue, 24 Jun 2025 13:50:46 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C3423140F5C for ; Tue, 24 Jun 2025 17:50:45 +0000 (UTC) X-FDA: 83591034450.30.650FD5D Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) by imf21.hostedemail.com (Postfix) with ESMTP id F333A1C0006 for ; Tue, 24 Jun 2025 17:50:43 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EGm2FSde; spf=pass (imf21.hostedemail.com: domain of 3cuVaaAYKCPElXTgcVZhhZeX.Vhfebgnq-ffdoTVd.hkZ@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=3cuVaaAYKCPElXTgcVZhhZeX.Vhfebgnq-ffdoTVd.hkZ@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750787444; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JfToG4W/8T4MN37HjczsbaeM2xUggUJm/FAUuhEMyM0=; b=ZbGCN1l057W0s2JWW66xpg6thBCx5Uirhz2nq/2/nqeIBdid97gp1cpizqj0JZ8eGXX5rT Mb+BKF3oM4ReRlajwvIQp1xGKO9hfrDmFtaSa7O+4P/syd2YlbXgHoh1ioB7JSFGJV+v2+ EnAABy2bksI6DSqT95OsiACfyZIKHqg= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EGm2FSde; spf=pass (imf21.hostedemail.com: domain of 3cuVaaAYKCPElXTgcVZhhZeX.Vhfebgnq-ffdoTVd.hkZ@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=3cuVaaAYKCPElXTgcVZhhZeX.Vhfebgnq-ffdoTVd.hkZ@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750787444; a=rsa-sha256; cv=none; b=I7S02J1JjRewqjWaJUl/cogNIVBNno+HN6UykV3USN/XbZzojPBIDCK4UyRfq39LQ8nRO5 +l89IGvHGpvNgWc8UVP4IuDAX2fFGz8cvLry9zqDMlVc9voCFFOK1szn1HGDHr3nXEhFLx QbLGD/Xn7IF0sXpcdtrC+gxqA7y7I8k= Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-231d13ac4d4so79338065ad.3 for ; Tue, 24 Jun 2025 10:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1750787443; x=1751392243; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=JfToG4W/8T4MN37HjczsbaeM2xUggUJm/FAUuhEMyM0=; b=EGm2FSdeAk2TKkRQG9WC4cLb2GufGeruw/0oloWSQRhzB1HVeQ+ayE8TEoaI3JRVGm R/IGqPhTl2TQdlyf7JPRHJriw0TkOlnUtaXBxuKZn7FFw4uw0l6ZKGjC6QOHX0ei9Joa K0GRoU9CvZln1KwzuwTHWVZ4yIYpS73qN15Oq0C/fSP2QuZAMOJlEbfNHD+IfH9ceNMG VAYDb/DutJz/RRWiu6WLOd4q1K06GsU84VLO6JMeFy+5fUvYEpwA3N19pqItCJFpeQnv goSwZRhlJlg3GWtUjlyvTs5S44iy5SRAtl0+62yqWSNwGfqOmRkeNdN6JdK7yZ7cGKI4 YdqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750787443; x=1751392243; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JfToG4W/8T4MN37HjczsbaeM2xUggUJm/FAUuhEMyM0=; b=lvTq1lD/I7UbXjwiaH71GLuVrwBMn+J4t8lhMXoxUxhy9vft/gcQunedc8vgSUNuwk PNTdA4p/cjaoflIibx9xSDn1Z/sIYz1ZNJDr8BOND/HHMV8hP7WiXtoiBo+nkfdJhzQR DJD8VZpxwNdAcytGd3ecMPL3DKrR6+udMKxYPfJcBBN3oNEQDiI3MuQrCIvSHUVNfRdf 9pcNs1ZoDocr2XIvWYa68QS/czG+m24PCX9ZjeSq3epHoJKWUvbHqCZTmqynxW7kbeQo 9yDQgiQ+HjgucZfY5ZXFRR4bDAI/ewj3h2OH1sMgQ/zLBXZeHZFrFaBzouY9UFsGqSvI aUYw== X-Forwarded-Encrypted: i=1; AJvYcCVhA6uijGSGvTjbHQL/FLZfPlPpW8HEvsu0ZTOwCENK9a2Kr7Mbpo/VKoPLnAy28DhoGZg69m6uuw==@kvack.org X-Gm-Message-State: AOJu0YxMSh60S6AfD8GcYzWBK5QsLMlXJhvZL2jCoBRDUWHo/lHBu1Zr 5Z9O8cKeRL7gSSpqCuQ6yUaeLR3KfDQyCWyrFjjhCpZWc6ngOAjhLFEIQ1OjqV3Piii11U6P8mB 7+2q1wg== X-Google-Smtp-Source: AGHT+IHcTeFnioFY8M93iMUzLc4QtOv451+sf1rj5bXR4qDBc1fgUxAPuE+TJu11BtZIFYPrgJNb4J/QJco= X-Received: from plbkr7.prod.google.com ([2002:a17:903:807:b0:234:8ec2:bf02]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:da88:b0:234:a139:1216 with SMTP id d9443c01a7336-23824087149mr3780495ad.44.1750787442548; Tue, 24 Jun 2025 10:50:42 -0700 (PDT) Date: Tue, 24 Jun 2025 10:50:41 -0700 In-Reply-To: Mime-Version: 1.0 References: <20250611133330.1514028-1-tabba@google.com> <80e062dd-2445-45a6-ba4a-8f5fe3286909@redhat.com> <372bbfa5-1869-4bf2-9c16-0b828cdb86f5@redhat.com> <11b23ea3-cadd-442b-88d7-491bba99dabe@redhat.com> Message-ID: Subject: Re: [PATCH v12 00/18] KVM: Mapping guest_memfd backed memory at the host for software protected VMs From: Sean Christopherson To: Fuad Tabba Cc: David Hildenbrand , kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, kvmarm@lists.linux.dev, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, vannapurve@google.com, ackerleytng@google.com, mail@maciej.szmigiero.name, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, qperret@google.com, keirf@google.com, roypat@amazon.co.uk, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, jthoughton@google.com, peterx@redhat.com, pankaj.gupta@amd.com, ira.weiny@intel.com Content-Type: text/plain; charset="us-ascii" X-Rspamd-Server: rspam11 X-Rspam-User: X-Rspamd-Queue-Id: F333A1C0006 X-Stat-Signature: uj794xwqk8kwty8o3hk6zmuwu1n4cmqi X-HE-Tag: 1750787443-183684 X-HE-Meta: U2FsdGVkX1/BSuirFLAxRt4igV42/lPeVu+98yKPguplriOGaUw3cd8tVI63PEm/leWFOLMfUvYpGsa1lTrR3mF4dNW0D+KKoXh8pWTsXw2xfq/goZWf3eKH1DYvFPY17RrBX7vnXn7/K6jSUUHbTeVUK7QJUhLTVxqnOxkknI2NZfySFeSzx1fsE+pXl0QohrwKqLhzQ4cIgO3qu6lD+CDidAxbQRSA2ghHjAPhZgtrmsJ1WS+eb49/46Rp+cb393dy8IMNkRr05kfZorFZqf5KdheRwOYZZObbEtCLe5RejKkbXMOfDLqIrP41i3PzGotP6zWhT9gwPcAKsj9mEShcLmmKOECfPYwclk9LQLPjihOAUBBvAiAu1/EEaf4nPlC3RjbqOpaSXgTQCmGkVjb11rJm9Ln04+wpnbkQsADqKpyQGUBwSGjQW6P3WD8qCDVkaxHBH4ITgccx/KWzKPlbH/fmpldU4M2/hnAL+GOBE+qWBieinPh6uaA9X4mCYLx2ganFyPqifibIRwt8VtmCoJQjcFrZd/FYr4qdqd4OcDZWMrvx1UqLv6LP0EgAXSS/3a5q4D85RAO/RKAwSQx0bLCgfWWcAyRznqI8KSXO04GzKyj2wAUOhBtC3ta9G+RKafxlcYyxcMeTSIYXBlz0pee+1/w71bkbl5alXSsaQSjmSj6Z2nemZ6r1VGilSp6fudf29yc+iREszqF1BklUu6LJowCHgGBy+5CgLH9mQnaRMe/eEsEpQB21veCV1vTRNKTGaHtGExZlmdfYyPfdJmZmyIzd1YGS9pGVCbUFF0jJF06xFsMPMKug116rJs1dOcDEpzvSWPu2MGW6U8lEkoDa13KO3QUPBcf5OK3y7x5lyNQeKA+3qA1dGzI2e5DcDL5vbSWjrlHjY/O7pgeHp/QKIYLcCpfU8gNSpBLK9i0DmFaTAUDQwVU2Ov+QFOwgraMF5hsorFelyWk Yh45Zzwd fs3DhgG5W0pSjL6Jo8RFLcKViTwBzYwin7Ea+Mhpa5ACXDsDRv7dEhx4SQCsh9DLgxZqmkhlGr+zCt3rrGfPk+V//ho4gZK6qvQovjfNLF80ZcEYrFOpK+xlL7q15dRiNu1JY3ws42bhjsGZob7Qj966MHS2YLQbv9TfHNsRagya3vvH0YSeycOsuH8NMlycL/If0dITxKOd66lHr9DiLGTvmkZn0K8gvSR15SPmF1esQFQwCAik69rlKo2VS2VvYdZwWTbPswt1SQSxa9rtpKBL91CzBabafpmClLa1Uj4p/vLLrBdcvRptQRAAH4CFmXha6gL4EmCMV7YR0p+ATXzzmgTsMdW4r0pqP6ugNA/K0UAi46nGbHHpaRo4esYrT8f64km5rRvLsFXc9uC0UlrPDVh5MY0K30P4JkW9RT/tQQkLvoaQLuNYH+PvlMzItUTMQScB57qS+w3jT43QEKpRoFdn3eKZ4wL0flSNDDPxCUPJ8TmZfimIhz/ZsPfbXwXrdT04Hv8tDiyKhI7SpLp4E2LoPrEzVq1ozQIj9PSanSMpjSgGx1Cys4TzoqNBm7PsrAd366QO8PDyoKFpdF+yZBRpYTDhyU7CZVygOY0josyYZuGXuacSW73NIrM7zSPDPa42XJOEwcrYkY6eNI6UZph/jb+tqszjOC38/9MO4XIafmhAnKhvPOO382L4MYBgB1XUysrGEXS+7ZT8MO7ja3NlInD+slBFL 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: List-Subscribe: List-Unsubscribe: On Tue, Jun 24, 2025, Fuad Tabba wrote: > On Tue, 24 Jun 2025 at 12:44, David Hildenbrand wrote: > > > > On 24.06.25 12:25, Fuad Tabba wrote: > > > Hi David, > > > > > > On Tue, 24 Jun 2025 at 11:16, David Hildenbrand wrote: > > >> > > >> On 24.06.25 12:02, Fuad Tabba wrote: > > >>> Hi, > > >>> > > >>> Before I respin this, I thought I'd outline the planned changes for > > >>> V13, especially since it involves a lot of repainting. I hope that > > >>> by presenting this first, we could reduce the number of times I'll > > >>> need to respin it. > > >>> > > >>> In struct kvm_arch: add bool supports_gmem instead of renaming > > >>> has_private_mem > > >>> > > >>> The guest_memfd flag GUEST_MEMFD_FLAG_SUPPORT_SHARED should be > > >>> called GUEST_MEMFD_FLAG_MMAP > > >>> > > >>> The memslot internal flag KVM_MEMSLOT_SUPPORTS_GMEM_SHARED should be > > >>> called KVM_MEMSLOT_SUPPORTS_GMEM_MMAP This one... > > >>> kvm_arch_supports_gmem_shared_mem() should be called > > >>> kvm_arch_supports_gmem_mmap() > > >>> > > >>> kvm_gmem_memslot_supports_shared() should be called > > >>> kvm_gmem_memslot_supports_mmap() ...and this one are the only names I don't like. Explanation below. > > >>> Rename kvm_slot_can_be_private() to kvm_slot_has_gmem(): since > > >>> private does imply that it has gmem > > >> > > >> Right. It's a little more tricky in reality at least with this series: > > >> without in-place conversion, not all gmem can have private memory. But > > >> the places that check kvm_slot_can_be_private() likely only care about > > >> if this memslot is backed by gmem. > > > > > > Exactly. Reading the code, all the places that check > > > kvm_slot_can_be_private() are really checking whether the slot has gmem. Yeah, I'm fine with this change. There are a few KVM x86 uses where kvm_slot_can_be_private() is slightly better in a vacuum, but in all but one of those cases, the check immediately gates a kvm_gmem_xxx() call. I.e. when looking at the code as a whole, I think kvm_slot_has_gmem() will be easier for new readers to understand. The only outlier is kvm_mmu_max_mapping_level(), but that'll probably get ripped apart by this series, i.e. I'm guessing kvm_slot_has_gmem() will probably work out better there too. > > > After this series, if a caller is interested in finding out whether a > > > slot can be private could achieve the same effect by checking that a gmem > > > slot doesn't support mmap (i.e., kvm_slot_has_gmem() && > > > kvm_arch_supports_gmem_mmap() ). If that happens, we can reintroduce > > > kvm_slot_can_be_private() as such. > > > > > > Otherwise, I could keep it and already define it as so. What do you think? > > > > > >> Sean also raised a "kvm_is_memslot_gmem_only()", how did you end up > > >> calling that? > > > > > > Good point, I'd missed that. Isn't it true that > > > kvm_is_memslot_gmem_only() is synonymous (at least for now) with > > > kvm_gmem_memslot_supports_mmap()? > > > > Yes. I think having a simple kvm_is_memslot_gmem_only() helper might > > make fault handling code easier to read, though. Yep, exactly. The fact that a memslot is bound to a guest_memfd instance that supports mmap() isn't actually what KVM cares about. The important part is that the userspace_addr in the memslot needs to be ignored when mapping memory into the guest, because the bound guest_memfd is the single source of truth for guest mappings. E.g. userspace could actually point userspace_addr at a completely different mapping, in which case walking the userspace page tables to get the max mapping size would be all kinds of wrong. KVM will still use userspace_addr when access guest memory from within KVM, but that's not dangerous to the host kernel/KVM, only to the guest (and userspace is firmly in the TCB for that side of things). So I think KVM_MEMSLOT_IS_GMEM_ONLY and kvm_is_memslot_gmem_only()? Those names are technically not entirely true, because as above, there is no guarantee that userspace_addr actually points at the bound guest_memfd. But for all intents and purposes, that will hold true for all non-buggy setups.