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 BD5EDC2D0CD for ; Wed, 21 May 2025 13:16:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 390EE6B0089; Wed, 21 May 2025 09:16:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 368366B008A; Wed, 21 May 2025 09:16:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 27E746B008C; Wed, 21 May 2025 09:16:19 -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 08A646B0089 for ; Wed, 21 May 2025 09:16:19 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 55A4A160433 for ; Wed, 21 May 2025 13:16:18 +0000 (UTC) X-FDA: 83466963636.25.32877BD Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf23.hostedemail.com (Postfix) with ESMTP id 7A35B140016 for ; Wed, 21 May 2025 13:16:16 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Rk7K8oN0; spf=pass (imf23.hostedemail.com: domain of tabba@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Rk7K8oN0; spf=pass (imf23.hostedemail.com: domain of tabba@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=tabba@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=1747833376; 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=VuCBq1LHvUmn2odvLxgs6fG8yadlcthuxdGwDQ52u/Q=; b=Qj+D5MHNp65F8aIwL3gBqvIQwW0XrXE1JvHE3FhK5e7yu2QtTtmCBpdFXDdG0w2P0mxe9q 79M9GKFMlYbsZPig8bfmPTMrp+tlqrHRBqPg2lx2PAXJ8YkHpuff1NwrdUCCQcrA3fYgtI QrjsQMr8iuNfwtR6edx+pLcbLl1QFbU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747833376; a=rsa-sha256; cv=none; b=oIYaKnO0axHPoWtQUEhg/4Kmw8MyqoXt9Yz6ubBLaX//VXAPMZIp5UxPSk2G+IX0+mf2Rl 2FQARNvpC7IdmuU/Nc02tONCkHfkKp3juvmNLDoNAZ3ymZFFg/unhg2XwUq+RiEtC4+4L+ VjmwOsaLrbEW54Crl7Wohcbj7UzGjIw= Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-4774611d40bso1132091cf.0 for ; Wed, 21 May 2025 06:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747833375; x=1748438175; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VuCBq1LHvUmn2odvLxgs6fG8yadlcthuxdGwDQ52u/Q=; b=Rk7K8oN0gqmG8LyzPiAYz/Tob4MUgS290rW6a1tEWA3mbImElLGDm98MNTgAS8dNmA YuJey4UOhmI1SItzpXs+oEbI5lm6SnX8qznCO2x3mTUsGZZiBMO7QUT9Ddb8Laxp8rNj cJVS0YOTeLgcPyhPPZdepD/V6FaheLnVrnhfllQQU/APZameh5ESeuvC/K//jJc9veHC ZYe43v0LMxxZSisvuWzxjpdWvJmJijVdpJRnWjm1DR8gNw/efmo15nfbDHwbrWfj9oBA 3/NoLyeYe1lMrT+oblIWKUKMx8LcIyCClSHSa0yr79lMkpLkB2kYyH88ueuZXe4uEd6N dB5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747833375; x=1748438175; h=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=VuCBq1LHvUmn2odvLxgs6fG8yadlcthuxdGwDQ52u/Q=; b=i/1p5rhg/yRpfzy3265z0Fn2Llu5nth+wgk5wi9pLpnzegqynQOJDCDmlj5HHdy1Fk POPXEQpY7Z5JZxCo0biYuSqsWbWouTwaE+mVRFVqjmOYC7Z7xyUnZkUvfY67Me0UerFE y6EElYMh3qlmeBv3CLviLHVUr0lDI9VEgcemcwuIGv6VY5mYBR58wUUCwwxMIoHbIS9h 5DYPsBOAMCy/nzcR+kslPLRx+fES1l6Afa+Y8gSiNMgSHf9/iFUncowZr4JPNJtrJEaD aKdh1d8rhRC5/eBWLh6EDXA0Fv9Za+g0VODDQNElMnQm51GdpjyUFt5i6ScszsDtis47 gcYg== X-Forwarded-Encrypted: i=1; AJvYcCVTlfuIMraPSVBEi4t5QowtSOiJo9Cf9Ead3SazVYLwlzj+ABLZVDSJNJVX3KokhJopScaFY7HQLA==@kvack.org X-Gm-Message-State: AOJu0YzLmfBjMgXUKkfoDx9+mXHyASJnvBZKrSQC2QY72/x2sbQQcntb /YoH9fHxNYkNgGncuGLpXzDKy4cwoD9fBh39WgzJ+jLWyAOfw09hIQQMzIVBwp+DNlTEaIVZkkk 6XO/v+0Ogfv16FOlcPYtuyW8qTe0r10OIHd9+syhq X-Gm-Gg: ASbGnctNCAyNbariOJhSC1Yt3ezNdHsMaW6vi210bYO5mJgVPKZQiiCB5nZWkAFqfNf P9nMo0QNcjr6KjXtqlVuFljVIU0UsL42tEWou8cH77JO+hQwajpdLGBeFeudcn5YTKHVkvzDjRo ayiytVs4CZwH73QiY3tU6gcW0adOraQPj1d15T04mvU0QZuAaWbgBaqLSUNFN4IrwlhaK2tFKo X-Google-Smtp-Source: AGHT+IEsY2DOtm1j/Iq7ToPRPKFUK44RMpFOS6HXHhjjXESPM2QyWtg5spoCOXC+/wyZDrMNwUIEeO5eVeLwGbiQRsA= X-Received: by 2002:a05:622a:50d:b0:476:f1a6:d8e8 with SMTP id d75a77b69052e-49600b8a607mr14222661cf.11.1747833375019; Wed, 21 May 2025 06:16:15 -0700 (PDT) MIME-Version: 1.0 References: <20250513163438.3942405-1-tabba@google.com> <20250513163438.3942405-15-tabba@google.com> <2084504e-2a11-404a-bbe8-930384106f53@redhat.com> In-Reply-To: From: Fuad Tabba Date: Wed, 21 May 2025 14:15:38 +0100 X-Gm-Features: AX0GCFsmElpyNGMgXEQvTVnqujAJSPexfnVcxsSJstUdYpKnZ4NFaqnN9_U6nGg Message-ID: Subject: Re: [PATCH v9 14/17] KVM: arm64: Enable mapping guest_memfd in arm64 To: David Hildenbrand Cc: kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, seanjc@google.com, 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="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7A35B140016 X-Stat-Signature: bp4crx4qnbcy49m4o4716z1ratr95p7p X-Rspam-User: X-HE-Tag: 1747833376-257603 X-HE-Meta: U2FsdGVkX19NNsf7DpcUozXse2R5zx4WCyeI4WKHCcji22cJ5qvWvNx5X9QI9HgnpuE2+rsp2gBjXXzJckvZxVdSeC4pZ1gMOFE6+sBZWWQm6VUNY7nwZE8zTbPEUhmd23nbyTD5/HC7IFCnoTLXc4gl7rTXbhbVOSKjfr156T4x8rJNARfH14E+RJF9gju0Nj6D3zPLSAKVtwNtyzFJ/Y1kK3PrrrNy8NRU+wKwUihAksLcbzGvEH7V2GdSLdn7NQbSBIADxsDszzGkjy5/XTeuO1FdmJoB35265v5Gtq71BWgVmTVUM5XY63nrFu/ktgqqykpsavxbWfBuWB0NcR6h/4DuCcqjVpsxcdyvlG1tnCMuu/3TQXMZ3fSLnjsS7R47DzeJyR2fY+MXf7yKVrEg2evNxmsb+jfhgIMYQUqFJmCBDDik0fMt4Kx/WiA62SMiBfQ98b/Ew9M2qau6tF/fJct6c/YD7rc/IumIKzzIwmqLb2XeBhIhdy7UnpfGUQzAGUnW0F7yFcLqUV4J1UbttRhcuC+pJDnnONpNy4+gxfCzo5+C8YzoldFNUJReOfMMUpWfJ8czsmM5eDEDTTKNYkPMsa5nPh7r2V66zKFeZh3033Vh6bKD93hHfkU7I5tqkRpaQfILsww4zB6v6kk64CeIM1XtcUCNjbKVqJeOst0MKxnLumwwojc4ATiyC/7hvuo+AGmVZdEfXYk2595A1+VsYZHFYIi9Pcudrwgc2uFoX26nDNwlAnfbRvreHmIpatwCPRmhfhQ7p9vYRrWnhNN2ufFD2bQ8DB/zwZq+HLgsE9Xl7VeNZTiVztlJUUbxtJG8zaena22l5LkQN9iVP8tYJAFBHzGeULvhAzEY69FsRfawz0UvqODtL1QTdoJ+E8ikNm8rBW2kPIE0SkDJIGMjIflNAznmMgPm07ln9itG3wCSnjJwQWYNb7+26aXr+t3Fco1ciMMaC+q bT1t5v66 pPAg7vcDIyX4JUqdXeIgmegvOBNK4A682g7l9ltyaUWmaYrYXYTyzJYfvHE0SsNJnW65fU4C80YRmAPEeFF+Md6UFbUvbDYo4jWkrCEz7pkCs2Lq/2IL2kwr+pcLIpIx2Z7EY6fIuik6S2WPJXuW6ECo4fR6BxriEs9zj+7ITeldffn5TqOhEmu7qG+Xq+uXRZcBnOKpHWkcVk5NU7QfaEtBwx1QgJe5ifJFydIBaLwkwj6vZPdrJl7UNZ+dHDTpDauQbdJDrBubcqakC8xP6I+V/WgUNqbAlZB0YaoGZhw4dJVyefKHzt175oe4nMs1JtHWYoccKRi7Z2H310WFmrQi10c+DLGTXzZ5W851P2hM4S6o= 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: Hi David, On Wed, 21 May 2025 at 13:44, David Hildenbrand wrote: > > On 21.05.25 12:29, Fuad Tabba wrote: > > On Wed, 21 May 2025 at 11:26, David Hildenbrand wrote: > >> > >> On 21.05.25 12:12, Fuad Tabba wrote: > >>> Hi David, > >>> > >>> On Wed, 21 May 2025 at 09:05, David Hildenbrand wrote: > >>>> > >>>> On 13.05.25 18:34, Fuad Tabba wrote: > >>>>> Enable mapping guest_memfd in arm64. For now, it applies to all > >>>>> VMs in arm64 that use guest_memfd. In the future, new VM types > >>>>> can restrict this via kvm_arch_gmem_supports_shared_mem(). > >>>>> > >>>>> Signed-off-by: Fuad Tabba > >>>>> --- > >>>>> arch/arm64/include/asm/kvm_host.h | 10 ++++++++++ > >>>>> arch/arm64/kvm/Kconfig | 1 + > >>>>> 2 files changed, 11 insertions(+) > >>>>> > >>>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > >>>>> index 08ba91e6fb03..2514779f5131 100644 > >>>>> --- a/arch/arm64/include/asm/kvm_host.h > >>>>> +++ b/arch/arm64/include/asm/kvm_host.h > >>>>> @@ -1593,4 +1593,14 @@ static inline bool kvm_arch_has_irq_bypass(void) > >>>>> return true; > >>>>> } > >>>>> > >>>>> +static inline bool kvm_arch_supports_gmem(struct kvm *kvm) > >>>>> +{ > >>>>> + return IS_ENABLED(CONFIG_KVM_GMEM); > >>>>> +} > >>>>> + > >>>>> +static inline bool kvm_arch_vm_supports_gmem_shared_mem(struct kvm *kvm) > >>>>> +{ > >>>>> + return IS_ENABLED(CONFIG_KVM_GMEM_SHARED_MEM); > >>>>> +} > >>>>> + > >>>>> #endif /* __ARM64_KVM_HOST_H__ */ > >>>>> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig > >>>>> index 096e45acadb2..8c1e1964b46a 100644 > >>>>> --- a/arch/arm64/kvm/Kconfig > >>>>> +++ b/arch/arm64/kvm/Kconfig > >>>>> @@ -38,6 +38,7 @@ menuconfig KVM > >>>>> select HAVE_KVM_VCPU_RUN_PID_CHANGE > >>>>> select SCHED_INFO > >>>>> select GUEST_PERF_EVENTS if PERF_EVENTS > >>>>> + select KVM_GMEM_SHARED_MEM > >>>>> help > >>>>> Support hosting virtualized guest machines. > >>>>> > >>>> > >>>> Do we have to reject somewhere if we are given a guest_memfd that was > >>>> *not* created using the SHARED flag? Or will existing checks already > >>>> reject that? > >>> > >>> We don't reject, but I don't think we need to. A user can create a > >>> guest_memfd that's private in arm64, it would just be useless. > >> > >> But the arm64 fault routine would not be able to handle that properly, no? > > > > Actually it would. The function user_mem_abort() doesn't care whether > > it's private or shared. It would fault it into the guest correctly > > regardless. > > > I think what I meant is that: if it's !shared (private only), shared > accesses (IOW all access without CoCo) should be taken from the user > space mapping. > > But user_mem_abort() would blindly go to kvm_gmem_get_pfn() because > "is_gmem = kvm_slot_has_gmem(memslot) = true". Yes, since it is a gmem-backed slot. > In other words, arm64 would have to *ignore* guest_memfd that does not > support shared? > > That's why I was wondering whether we should just immediately refuse > such guest_memfds. My thinking is that if a user deliberately creates a guest_memfd-backed slot without designating it as being sharable, then either they would find out when they try to map that memory to the host userspace (mapping it would fail), or it could be that they deliberately want to set up a VM with memslots that not mappable at all by the host. Perhaps to add some layer of security (although a very flimsy one, since it's not a confidential guest). I'm happy to a check to prevent this. The question is, how to do it exactly (I assume it would be in kvm_gmem_create())? Would it be arch-specific, i.e., prevent arm64 from creating non-shared guest_memfd backed memslots? Or do it by VM type? Even if we do it by VM-type it would need to be arch-specific, since we allow private guest_memfd slots for the default VM in x86, but we wouldn't for arm64. We could add another function, along the lines of kvm_arch_supports_gmem_only_shared_mem(), but considering that it actually works, and (arguably) would behave as intended, I'm not sure if it's worth the complexity. What do you think? Cheers, /fuad > > -- > Cheers, > > David / dhildenb >