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 1918FC2D0CD for ; Wed, 21 May 2025 14:15:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5857B6B00AB; Wed, 21 May 2025 10:15:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5359C6B00AC; Wed, 21 May 2025 10:15:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 425726B00AD; Wed, 21 May 2025 10:15:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1E5DE6B00AB for ; Wed, 21 May 2025 10:15:19 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B1473BA926 for ; Wed, 21 May 2025 14:15:18 +0000 (UTC) X-FDA: 83467112316.13.61D5DD7 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf25.hostedemail.com (Postfix) with ESMTP id C7F57A0013 for ; Wed, 21 May 2025 14:15:16 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wfix64ot; spf=pass (imf25.hostedemail.com: domain of tabba@google.com designates 209.85.160.177 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=1747836916; 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=3WzAnMtwICC8te5utymAkjaArInvb4ahl245wyxmDhU=; b=QxQPlIQGoFkPViSxmuZIzhdNWIOCc0DkRCHNQqtVEBSuCvNgUMp9hBmow5b3zYiaZiC6Jd I7v9Fv9UU1cZHAnR3urRLaW4jTYd64+5WitmXsOGcDhqkUwoKAYgYvlL/kogDqPEY8ZeD2 +Qr7RZ4PlvytesTKMq0PxhzSaa70Vqw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wfix64ot; spf=pass (imf25.hostedemail.com: domain of tabba@google.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747836916; a=rsa-sha256; cv=none; b=Mt6nr5XXF+YQU/UJCqMwWR1+LVHE1m0seGbPm8Yxo9kvog86c7te1SKYfHgMKLPBdwsCE2 BkecFtuWZ60FaKNAJq95a5y86fpLQ61W+5BwkgwJLsZW4fAdRnpzTxUeDeUxOpsACYo4nj ud7X0JGx7z9m1PN2whZlAMGNT3k7umw= Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-47e9fea29easo1716711cf.1 for ; Wed, 21 May 2025 07:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747836916; x=1748441716; 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=3WzAnMtwICC8te5utymAkjaArInvb4ahl245wyxmDhU=; b=wfix64otQt0ncOz78f/razqHCS9rABNjuszDuLyynQA9Du4cqncqW8tGQY9sRmVjkA bx+4rD92+pGAJw0X815kLVaNcbyPob68W1YHPZeyR+w2MiyGG3sZiDhd1MBRC7i+GCpn 2VQSJjrF35q3DhIFiBiSP0a5n/UBPl0oI3cLky9N4IeYFOYf4uxtL0csJpz7xQ4YetWE cmSGx3y3zCMBuk2TrRYYOEhHlmuaeOaskVGJvXFwvdukRXxegb1eLsps3WPElCyYeMeF AfDILji1PBhzpSd84mv0Iiiq4ER2HPf0cK/UN2T3zwGM4wW6BLFlN8JNDuV3FBKUMg2o zNbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747836916; x=1748441716; 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=3WzAnMtwICC8te5utymAkjaArInvb4ahl245wyxmDhU=; b=esYcikitUdxS3YmTEXIcGdxNff/BLmWuwOgDp9gdw95ygOCD31L74lUPkaNmkeJ3xg Iwcp+KcqRruPiJBaqKpxv55mjBWsCgidNPkYoRQWHr0p9WyeauT0kSCy+yypAW3Aasmg 3SxLdQ3HNtKlb8JGbWND8jY0uR2fb+OUnSveLBEfsEB+0vsJ3Wl/azm/Xec3+T9euN+D oVOwouDhvJmwe7fHPbbVM3/X7alwoQBh6Q6XVAw1+WvVTI5ss/+QoHSJHK5gRW1ldsq/ FjZKDMPi+RMSFsOObFMd7bZAC4vZuYp/Mg+oaHachxrgkd8IYuqKmV95XXh1Y7gTyhPs HT+A== X-Forwarded-Encrypted: i=1; AJvYcCVL2cP1ZkTf/eA5vi+/t5p0epG0He8eXn3WmDfKIXV4FFg0WHbPTmzxi3k5ItCAgx4E1e0DUJ57PA==@kvack.org X-Gm-Message-State: AOJu0YwhsOsmbqPaLR1ZSM67xfQ429IfzWNfdt/5uuyp+imXYpTHQ7fA 3nDY9SM0mzrZ+wE66AbDubVz1G4CwOKWcFmbsClw+hKrp3kI7gNkBEWtLrrbUt5QUsjIjtymWof ZzvemHKKVj9c8QVh70Qja/+NSoSMeQlG4BKXDVoWY X-Gm-Gg: ASbGncuClUUAxxQhJpfFtnGk457bDTkzbPcWXO3fVtLIMryOZ7FXBAX3300fty9iMJG Zg75TsUXpO/iDRk1cmrBg4nPfOYsoE8IzgSJ7g74ueGQDH9UVsy+c6QS2pN6HyQZhmoC1rJzRa9 MMuZPOvXkFNAGtyFPHN6vxpvDtgGeXz9prkq+mLkp5GI3C9iqRXyFYJVos8MwWW60zemCpPh8I X-Google-Smtp-Source: AGHT+IEn5V+JWD+UauK6mQDftJkyNEx0zMO+Q169cK9p3MaBFwYpfUCXSSLf4XNPPuvJL0iGrFy2j+E3JL/Lqw/qYdw= X-Received: by 2002:ac8:5344:0:b0:494:b641:4851 with SMTP id d75a77b69052e-49601267af3mr13541891cf.27.1747836915564; Wed, 21 May 2025 07:15: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> <5da72da7-b82c-4d70-ac86-3710a046b836@redhat.com> In-Reply-To: From: Fuad Tabba Date: Wed, 21 May 2025 15:14:39 +0100 X-Gm-Features: AX0GCFv2FNWFMwS3kSPiKr0dVnY2fcYTXMVpdcfakJ_Ca04MIfPa37C-aPPjPqA 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-Stat-Signature: ex5xiz6zzid8gsn86k5iztus7f1uj7a6 X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: C7F57A0013 X-HE-Tag: 1747836916-469831 X-HE-Meta: U2FsdGVkX182eOvM4X4jOQwrBhFWsVNykPz+oxYx0Ddd/yF+vgjYHfWhFRqcuaDljZTX/7f6djx9bpIGB/qxiWFDs1yT9NtjBMaq184iecm8iPs2OvKZJYv+Q9KVDSgTyBiyFcTu1jEVacRQCQDts4Xh+uA4nPZMOAM7JE4MA+vSrBJeN82ttSltF901WcC6YSFoAMdzJLmsykmKAVk+aUGgEI/4FLv9ZuZFdRTB+y1R+AWQITc5GhMgdqh/il6/5+hodzUBrUI7wlS+Nfmh8i7yV1tpV1cd5ONYfKT3l4yaMqjdNKNbBF/IcvD6ZwCKiJFYRZURZ6MMLOW7Bd1hmIjoFzL/4E3BhuHim75AuSbFZGYnatGX9NXsOvuS/GGFCwBANagpW7br/Qdn6pG5U7+vdeOfnayVsP64IQM/WoM3kPPQZceX0vL3xvqatnUCFKH6u6Q9cP4uzC9Hjial0sx1eZElx0mP3o33e437O2cmqV1FcPx+q+xSOc+5pNRmaojO2fPguFw1ajw8WRwtfO72E4cQ8oFoKQlWOgNUB7mePsklXSS1q3haLBk/8e+Nfc1hsBmkeYtTYCHCt3Kln49BCUYZHgcGwm9VWL4uUdmvVlEvc5Ya3LSuVE7xiSS/av8ss0quHmi0g5RKXL89D9ExHH1JCp0xYarsaJMEqcD0HD9FmdOwbrFKovbcYq9UxEk9hsDXyliAg7e0rEQPhZ9usefw7lxjz6Iod6HW8UobTzHejnwNv4DWmcTZr3XsEH3JGNoAuFKS3rd5BnQUCFgnuXchEeRQkjhkdPpeKVautB8BNO0NqZVsiJbJMJ56N0zkGr61cB/o5PGoB4hNeYpA1Hlf9CMwfTXWA37wzCaCdZYxah2itiIXc26H4zDINqKa9PKO1ExHVP2WjNuLsLiE7y2EGpRlkCD5tJkhHQiCcDa1FnH4Rny/JbuJGuNfCEwZWvPm9qWmvQDl6X7 0Dy3pirZ SfmD+IRr5eR8qtWfi5nE+uehtuJB0HyNuOwE7uLjqTdtG+IjTNmY1h30XYUpyh/Rfof1saeN18u0O42+vQA/7YNadDsX6rv6Klbb+/SbU7Nqdbi7zYFKgB1KuIay2iARlIQeBtxoLZzvu0YSCEMlCgTkWlJfbKVmZDjd/ZJo1m4vPepSOhw4nUohjy15Gmj9CvFqoAysNvLZyD7WjNujACCfK5P3lc9xNVXad/jkNELJ6MKixlFMJIeNmsGpBY70+pkjdO6Wg4ttH1BggZh8UgeYKjuLpkh4lx6OhHeDFXfmUKVCmCpYRrphV1P01/Ym3424/klae8gcb6ycm0SOuaHwl5DmALx93gEk6qOje2kPiqgw= 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 Wed, 21 May 2025 at 14:45, David Hildenbrand wrote: > > On 21.05.25 15:32, Fuad Tabba wrote: > > Hi David, > > > > On Wed, 21 May 2025 at 14:22, David Hildenbrand wrote: > >> > >> On 21.05.25 15:15, Fuad Tabba wrote: > >>> 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. > >> > >> Hm. But that would meant that we interpret "private" memory as a concept > >> that is not understood by the VM. Because the VM does not know what > >> "private" memory is ... > >> > >>> Perhaps to add some layer of security (although a > >>> very flimsy one, since it's not a confidential guest). > >> > >> Exactly my point. If you don't want to mmap it then ... don't mmap it :) > >> > >>> > >>> 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? > >> > >> My thinking was to either block this at slot creation time or at > >> guest_memfd creation time. And we should probably block that for other > >> VM types as well that do not support private memory? > >> > >> I mean, creating guest_memfd for private memory when there is no concept > >> of private memory for the VM is ... weird, no? :) > > > > Actually, I could add this as an arch-specific check in > > arch/arm64/kvm/mmu.c:kvm_arch_prepare_memory_region(). That way, core > > KVM/guest_memfd code doesn't need to handle this arm64-specific behavior. > > > > Does that sound good? > > Yes, but only do so if you agree. Ack :) /fuad > -- > Cheers, > > David / dhildenb >