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 70DDDC71157 for ; Wed, 18 Jun 2025 00:40:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D9A0D6B0088; Tue, 17 Jun 2025 20:40:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D72106B0089; Tue, 17 Jun 2025 20:40:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C88166B008A; Tue, 17 Jun 2025 20:40:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BA50D6B0088 for ; Tue, 17 Jun 2025 20:40:27 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 40325161514 for ; Wed, 18 Jun 2025 00:40:27 +0000 (UTC) X-FDA: 83566665294.13.82C5C03 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) by imf02.hostedemail.com (Postfix) with ESMTP id 754C980006 for ; Wed, 18 Jun 2025 00:40:25 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kJs2MnWB; spf=pass (imf02.hostedemail.com: domain of 3-ApSaAYKCJ8RD9MIBFNNFKD.BNLKHMTW-LLJU9BJ.NQF@flex--seanjc.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3-ApSaAYKCJ8RD9MIBFNNFKD.BNLKHMTW-LLJU9BJ.NQF@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=1750207225; 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=k/9aJlHm+goEi0z8rczKBwE3W8+faYM+8dllr+qUaic=; b=OH5UZ5koge5AvgWbQ8ufUScRpz3Ct1mOCNw0aexcyi0W/L/UMVwvu9GKHBJ516SQIHHica 8uCfIPMzdbVzBLM1UpvUSmzf3mob2QUjqx4wn4Fsk4vUzJuZtB+3g1Sc/vH0CD9wE6ctjn f4AHDzDfWEY/ZwxRsCI76FMdADawTrI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kJs2MnWB; spf=pass (imf02.hostedemail.com: domain of 3-ApSaAYKCJ8RD9MIBFNNFKD.BNLKHMTW-LLJU9BJ.NQF@flex--seanjc.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3-ApSaAYKCJ8RD9MIBFNNFKD.BNLKHMTW-LLJU9BJ.NQF@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750207225; a=rsa-sha256; cv=none; b=6rLCVkxTGp6z0cbRO9IX82BxrdTn9+BWzzp59PcBWAz9p688Va7tC43zGfdsh16rFc6fRG qvn24DMiKjvAQNwvb4b+IvPdadkmCkbbh4muvl3Y01NrpYmqHeM0w/RPLJVttjxAENGrAg lpJnYXyB14TE82bvnwhgdTImJe0yaGM= Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-747d143117eso5191786b3a.3 for ; Tue, 17 Jun 2025 17:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1750207224; x=1750812024; 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=k/9aJlHm+goEi0z8rczKBwE3W8+faYM+8dllr+qUaic=; b=kJs2MnWBmgJP5LZEyZqh85BAbErQYsaaHzMuGA+F423DCuFiWKCx+jjkCY5Nq7BX5r KmMhiySyZtaK3GQG2VD2P0jOPeWFwIjiDmRCRk3h7vIQ/4BI8RDB9A4i4C7vJ5WDaBzO YsTUtFWyXptiq6rCpWcLr9el0Z1hRFS4fNPQZ753TKW9DKm6Z+MKnJIThJBDeblcLKZJ uFFKBE9jwUXakvA7/lKEdEkA/T9p1v+c21z/awbyebuUpZ9JfxIT2fNrr2K/4iJOjAQL /oAjNMNmfb++umyET1KKKIdw/slCGnRxtPw/6TxnonqbHUKkBVxxTYnyfXjlAqeLu8PY S7Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750207224; x=1750812024; 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=k/9aJlHm+goEi0z8rczKBwE3W8+faYM+8dllr+qUaic=; b=FfJKMn6lotYFg6qXr6Y5vbelvYvOSdV/G/rT50QJXWq6JuITRvqZSXpj7Ie/yRfmY4 +y4NmuQcXx0Vpapb7EEGImQeq875WfpB74LDB1OBOmYtQ7MZvDnZxqJuwkR5gdswqN5q rO+8zujpv2V7sLVr4TVwAei4cJXm1rPWZbO+/3nSq7f1BmUjv36SZQpM19070Kmcfm44 szIEP0JeQLpKdKkeHgdUwXJRzadSkjkqI/5gBPkWEUPCP4X40tOoe//D63ZH/O9e3iqW 44mto47e375XQFKmOAp2qZ2/RgkxYqa6LqBIlteNPJMXhDnfEhO1X3wUGiBNDOIih6UM uLCQ== X-Forwarded-Encrypted: i=1; AJvYcCX4nCLi0csEz3M3r+kn8dVz26x/xj90fUyN7nu87IgwpWXl/t6b7+L2oOSVGDy59y9JSpEyuFU1cg==@kvack.org X-Gm-Message-State: AOJu0Yzzksmgr4qtGf6zxtqAWaO0SIvH1CeyCbSUtHCERibM7+XUPLdI CYaervcg2Pu1QN5nd6TlzjzBLZFSJA+NvkDhzNTRz7u+cZTuDPG+jMmLvxJH2DdCGoVFNbKkOk7 hWh2Kkw== X-Google-Smtp-Source: AGHT+IFnYwYFUetnQyZQ6TOSbasVaExJ476XGu1ioWQ0wajRmFxtx38py86YH2tJpmtJ5k1m1wGBTN+0spM= X-Received: from pfbch3.prod.google.com ([2002:a05:6a00:2883:b0:746:22b3:4c0d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3a19:b0:746:1e35:3307 with SMTP id d2e1a72fcca58-7489cfd5ee0mr20211902b3a.14.1750207224147; Tue, 17 Jun 2025 17:40:24 -0700 (PDT) Date: Tue, 17 Jun 2025 17:40:22 -0700 In-Reply-To: <701c8716-dd69-4bf6-9d36-4f8847f96e18@redhat.com> Mime-Version: 1.0 References: <20250611133330.1514028-1-tabba@google.com> <20250611133330.1514028-9-tabba@google.com> <68501fa5dce32_2376af294d1@iweiny-mobl.notmuch> <701c8716-dd69-4bf6-9d36-4f8847f96e18@redhat.com> Message-ID: Subject: Re: [PATCH v12 08/18] KVM: guest_memfd: Allow host to map guest_memfd pages From: Sean Christopherson To: David Hildenbrand Cc: Fuad Tabba , Ira Weiny , 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 Content-Type: text/plain; charset="us-ascii" X-Rspamd-Server: rspam11 X-Rspam-User: X-Rspamd-Queue-Id: 754C980006 X-Stat-Signature: 39x8tz8aq8xf9mkzgkbzpycgyg41xpsg X-HE-Tag: 1750207225-41994 X-HE-Meta: U2FsdGVkX1//A3qY9yaZBH0ZFspWG2Ih5+9qCpaTsUjgrA5VYSYP3TyFh0vaSLY0LERns2UlBBoOmTvycfljJdg4PTwRYtaf+TJG3DhjXq/P9l/Mvt+kOOG4UXRH1TCMiddxGGWUAdu/BAheDcPyVNIxg+f3jUvx3KD7aJy8njj+oG1QPhCoH1cT8IMYf1QZUplJ5B/QTFybtqxofJxVs8R21lcdOvQBQ9kAkPUEZXeDGPNS0JhyVCNj/aokX3fAVQX6jlFYEyn0ULkMvTDrDvNzbBhCkMFw+1vKeQqGjPnEKpgOnrFONQC2M+UbAxxKyGUmQb+1PK1tl4uBwlJ9cRQGMaoPVZuQknepLeeK6dau/WWm3AxPNdfGWyKubBNvttnOM+/3f4TENw100WPndQCK3UOTLzYmM0i1qk48PVoRrI6xhtulpPu8FcEHhXIZ0jTw0B5LGQ/G/DNozDYjiHh6X7CZkodho1jlgx5aY8ckloVcI8PZMjVTdb/gYHvPRPnm8HOOE3hvM5xuTxOCnfqACHvaDiBcJdppk4qYJoVZVNmA65S4ndLd1utrUdCgde8j6jr6Ghh1aCaFtgO9lCIrJ6QecGOTuc5d3l687X8KzBhicz2NUWKLPQ4N9+4eGUOXibZALWVqM3Mc3mgUvdjPNjxWVq5fS14sice17nEI1QUnALLQ4TgOsQnxOqQBWUu/3x+pUP+bi7eGYintFOlNYyJOY20RMwxeCKC336GljFRg/QQWVal1sL89orTRnzZe95mdD8WUd5FW0zEfd+48E9BCITgk8MbfDI8qYpC3SSQi42YQ2glg3OdGkoaidymyOoGVUCaeOkyBskzbcm4bSupQ9hJ0dRFkSB9mrIi4BUInRrl9s8278aQiWX3wuhYorSJodX5PPaLEP6TLqydqJQbbSR5gsPt19cdk/8CcDRwDVGtld8TdGY0+ZUnMpSCOSiDMqV+OE8nIl7u tp10fL0M eIgXDo7iPobai8jBogCdJ3+CYLr8caE08+sGiWwFprQ8G2h4GDGtlpOdWYHexbFDtx//Bhzg3Cw6FNN1nzwU0F59LuawSEX6ViUQRXWQG0pH+2QuewtA0MLlbv9nbl8bRVMq2XBGdiD6aYjMGcuerHJzduTyfQ66yVD+MdWnxmOSZxJWCLP/56ArqGt5OyieihE/UDSslL7gPAWG9pQ9dv7zlV2ax7E/ncZA8wkLul0x3h+bGAe7t5M3ZwVr65e7rSsYtXkRsU7nJ4aKicUnIUY3su5DgOfSyD4sz2Qaz05AFbTGvo2HIyKakf3tT61sQGw6pYLbE+Wy02XoyOBPjjgHsCI7Buq36SdlxfW+tTVozrK8XHExejQ7tuKNFb4cujHhOr47BF/9uB4JU+PPVdtvtsZ2HTDbtOYagjCwqPOme1RWJjofLbJE2SWggmII6CH1sD2NhR+K/MnIccUsvP7GR9psDKG8El5zHh1ueCQ299ij4ihRca36FeYOUYCZ3Vcf+3z6PqWSRrkJC0tnD/PbWXcCRE6ymLDO4dbbOyeECQg8J3bSzHjAvJp4yu5x4GfjYGHHJ/miR50ZvkX92bojvdogkwkm+7fYp4ElN1MCxgORHnBvLgo9jnKBACzRMUaEpmM0oh0jCPLzR+xbdE2tcw5yQnm2ZA3GQ9FlgPWpUskTC/TND3L4G+55C7SM1aS3Xwysqic5MGZu2ep0pc986eHhCeChrK4AX 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 Mon, Jun 16, 2025, David Hildenbrand wrote: > On 16.06.25 16:16, Fuad Tabba wrote: > > On Mon, 16 Jun 2025 at 15:03, David Hildenbrand wrote: > > > > > IMO, GUEST_MEMFD_FLAG_SHAREABLE would be more appropriate. But even that is > > > > > weird to me. For non-CoCo VMs, there is no concept of shared vs. private. What's > > > > > novel and notable is that the memory is _mappable_. Yeah, yeah, pKVM's use case > > > > > is to share memory, but that's a _use case_, not the property of guest_memfd that > > > > > is being controlled by userspace. > > > > > > > > > > And kvm_gmem_memslot_supports_shared() is even worse. It's simply that the > > > > > memslot is bound to a mappable guest_memfd instance, it's that the guest_memfd > > > > > instance is the _only_ entry point to the memslot. > > > > > > > > > > So my vote would be "GUEST_MEMFD_FLAG_MAPPABLE", and then something like > > > > > > > > If we are going to change this; FLAG_MAPPABLE is not clear to me either. > > > > The guest can map private memory, right? I see your point about shared > > > > being overloaded with file shared but it would not be the first time a > > > > term is overloaded. kvm_slot_has_gmem() does makes a lot of sense. > > > > > > > > If it is going to change; how about GUEST_MEMFD_FLAG_USER_MAPPABLE? > > > > > > If "shared" is not good enough terminology ... > > > > > > ... can we please just find a way to name what this "non-private" memory > > > is called? guest_memfd? Not trying to be cheeky, I genuinely don't understand the need to come up with a different name. Before CoCo came along, I can't think of a single time where we felt the need to describe guest memory. There have been *many* instances of referring to the underlying backing store (e.g. HugeTLB vs. THP), and many instances where we've needed to talk about the types of mappings for guest memory, but I can't think of any cases where describing the state of guest memory itself was ever necessary or even useful. > > > That something is mappable into $whatever is not the right > > > way to look at this IMHO. Why not? Honest question. USER_MAPPABLE is very literal, but I think it's the right granularity. E.g. we _could_ support read()/write()/etc, but it's not clear to me that we need/want to. And so why bundle those under SHARED, or any other one-size-fits-all flag? > > > As raised in the past, we can easily support read()/write()/etc to this > > > non-private memory. > > > > > > I'll note, the "non-private" memory in guest-memfd behaves just like ... > > > the "shared" memory in shmem ... well, or like other memory in memfd. > > > (which is based on mm/shmem.c). > > > > > > "Private" is also not the best way to describe the "protected\encrypted" > > > memory, but that ship has sailed with KVM_MEMORY_ATTRIBUTE_PRIVATE. Heh, I would argue that ship sailed when TDX called the PTE flag the Shared bit :-) But yeah, in hindsight, maybe not the greatest name. > > > I'll further note that in the doc of KVM_SET_USER_MEMORY_REGION2 we talk > > > about "private" vs "shared" memory ... so that would have to be improved > > > as well. > > > > To add to what David just wrote, V1 of this series used the term > > "mappable" [1]. After a few discussions, I thought the consensus was > > that "shared" was a more accurate description --- i.e., mappability > > was a side effect of it being shared with the host. As I mentioned in the other thread with respect to sharing between other entities, simply SHARED doesn't provide sufficient granularity. HOST_SHAREABLE gets us closer, but I still don't like that because it implies the memory is 100% shareable, e.g. can be accessed just like normal memory. And for non-CoCo x86 VMs, sharing with host userspace isn't even necessarily the goal, i.e. "sharing" is a side effect of needing to allow mmap() so that KVM can continue to function. > > One could argue that non-CoCo VMs have no concept of "shared" vs > > "private". I am that one :-) > A different way of looking at it is, non-CoCo VMs have > > their state as shared by default. Eh, there has to be another state for there to be a default. > All memory of these VMs behaves similar to other memory-based shared memory > backends (memfd, shmem) in the system, yes. You can map it into multiple > processes and use it like shmem/memfd. Ya, but that's more because guest_memfd only supports MAP_SHARED, versus KVM really wanting to truly share the memory with the entire system. Of course, that's also an argument to some extent against USER_MAPPABLE, because that name assumes we'll never want to support MAP_PRIVATE. But letting userspace MAP_PRIVATE guest_memfd would completely defeat the purpose of guest_memfd, so unless I'm forgetting a wrinkle with MAP_PRIVATE vs. MAP_SHARED, that's an assumption I'm a-ok making. If we are really dead set on having SHARED in the name, it could be GUEST_MEMFD_FLAG_USER_MAPPABLE_SHARED or GUEST_MEMFD_FLAG_USER_MAP_SHARED? But to me that's _too_ specific and again somewhat confusing given the unfortunate private vs. shared usage in CoCo-land. And just playing the odds, I'm fine taking a risk of ending up with GUEST_MEMFD_FLAG_USER_MAPPABLE_PRIVATE or whatever, because I think that is comically unlikely to happen. > I'm still thinking about another way to call non-private memory ... no > success so far. "ordinary" or "generic" is .... not better. As above, I don't have the same sense of urgency regarding finding a name for guest_memfd.