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 57872C54E65 for ; Thu, 22 May 2025 10:25:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B307D6B0082; Thu, 22 May 2025 06:25:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE1A86B0083; Thu, 22 May 2025 06:25:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D10A6B0085; Thu, 22 May 2025 06:25:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7EADA6B0082 for ; Thu, 22 May 2025 06:25:01 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E6D71140DBB for ; Thu, 22 May 2025 10:25:00 +0000 (UTC) X-FDA: 83470160760.22.0D13298 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf28.hostedemail.com (Postfix) with ESMTP id 1C343C000B for ; Thu, 22 May 2025 10:24:58 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Drs0zoNG; spf=pass (imf28.hostedemail.com: domain of tabba@google.com designates 209.85.160.182 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=1747909499; 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=x47DXf0LwZVNiKlb3wkbXTC/sIecpIFw6BTMrRFpupA=; b=aSKi9i8NbFIIQmw0k9ulau6RVb77Y8dzUPkUZL0JD/o0nsY7S4C1kOk0P2yrMAuPQOXhku PHJ4ksY9Tb0WjWka5xW8vpvHbI5oCgc3CeOlupIITcUjdTzp/DAVnsGZSzbAZcf0E384f+ CRxJVAGpjscmySjFAz7vmxhU6LdBdWY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Drs0zoNG; spf=pass (imf28.hostedemail.com: domain of tabba@google.com designates 209.85.160.182 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=1747909499; a=rsa-sha256; cv=none; b=E9OmzRacr2ZQCR+d2HHUhh4VEp7lZveK4cmN8O3Pgc/h1zCKO2RD/BT1/u9sJ1lA3JL2IS RMc0kKs7eUe7dDmHngAjiTURJSTHJj70D5aqbF+w0Au2VYvt2J/s0zLPqAI03zXaJUoN7p bN2utHBCJhLZ1mqumCAwA57DQjQM5To= Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-47e9fea29easo2108361cf.1 for ; Thu, 22 May 2025 03:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747909498; x=1748514298; 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=x47DXf0LwZVNiKlb3wkbXTC/sIecpIFw6BTMrRFpupA=; b=Drs0zoNGYAFTxLDB5RcRTWApcRYyX64yA3oZY2mp0GvjS1szh0kdByXSa1yvkdc89c ozF2vVg9aV8R/PCCrjvdJdDvOs2HjxFeVbdf+GsrWVmqedyyH7XTt2e69UQ3kcCl3y4n OsyHLYjUwyepuPx1cfpPepdN1wme/4yWcTABuzirp4ictK8v5d/uuv6n13El70nXH+wa 4wpsAK32TUC8MWUypS26m5rk6ia9VBCWthTjuXdfw645CYVYSgV03jRW6jIw4OZklZTL Dn7hXOhLMzEpReTHVGzBUJMig3Ymbf8rNC/y+Xug0iGYtb0HueRelk2u7CVBbTdjix+l hz6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747909498; x=1748514298; 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=x47DXf0LwZVNiKlb3wkbXTC/sIecpIFw6BTMrRFpupA=; b=depT9uDVi13WiN/myaQnyV0zOr5e1TS98gZCNC39jWD0JLsbgEr8vkrjCYuxPUaiX3 xiMmBvqMUn/zqhtGPFyRm1R6ZxRGQf0We8Tnt7GWhNcHGTxeKVlGHYU/oVQUnrQ/VJsi HBmfsVN9qRLIVV1gMk1xcNI0TIyK9ktYRL4k8yiRSDVrJXCrFe9dWEwjjTFIPPVUAPfj eSBOqgBCdsR8asYR1aqcces9bIOzbXf9HeUvgqHubWqNBZNgt5+baV1Wu4DwsCOfULB4 +nlnBAnnFYoaLI29GqW+WOySqsaZh0Yjgn96z9Luv/F4Bmd5keF7sByPfyK+0FaER0Xo i0Bg== X-Forwarded-Encrypted: i=1; AJvYcCUD7fNHBv2YBrmtshKY4j07CJ8Gny/8DRtgF2NFNzhqbsWv9znkf1ydGTmIpU+Wjf0LYMunt95jrA==@kvack.org X-Gm-Message-State: AOJu0YzFMIEaKcuY5KAWV30j2GLAs4vLCGH2PHLqsdP3O4tDrlw2cBwP bbvD1+Y2ItsouuiY6jsAtbTYrRlJ5QsSrUYO+fPdkGktsYSSwaw2SISqkkLQ3V8qTMWJZhhfsK3 FSpLzwgfXfj1FM1kgU/HBe8gcUAFSQwSlYFtKsY3v X-Gm-Gg: ASbGncsnujX3bBbjugcRAZLEdxHO1r82+p7hX3+HP3z07OlWl0gTU05q9ugIxss7HFh +c5Rf3h9fNxDBssT/AnUz1vxvVCGk/h9i/uius6Q047LPH1dJm4qCgo4dcJoef084rVWY1IUXxO yN8MrWLYZyWCEPjy43N9XbhG0wqdowv92kJQuZCtF78uw= X-Google-Smtp-Source: AGHT+IFFRgUWI0NU06qVkWoFb8Z9kmLtjgaeDRLO2zA6r6AJF9Dvjx1JKI2vr0sPeMh6lsWF+cIVl+Fc6Vil7wvNJhg= X-Received: by 2002:a05:622a:146:b0:47d:c9f0:da47 with SMTP id d75a77b69052e-49cf19955e0mr2417021cf.19.1747909497875; Thu, 22 May 2025 03:24:57 -0700 (PDT) MIME-Version: 1.0 References: <56e17793-efa2-44ea-9491-3217a059d3f3@redhat.com> In-Reply-To: From: Fuad Tabba Date: Thu, 22 May 2025 11:24:20 +0100 X-Gm-Features: AX0GCFufUrCbWyY_AlAGFwCTlF_4veL5Nb4vNKt9zfv9zoivg-KO6gYnG0vZF1w Message-ID: Subject: Re: [PATCH v9 09/17] KVM: x86/mmu: Handle guest page faults for guest_memfd with shared memory To: David Hildenbrand Cc: Ackerley Tng , 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, 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-Queue-Id: 1C343C000B X-Stat-Signature: bimt9y9yw3wj44afjfhsgp63iso34xw3 X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1747909498-188621 X-HE-Meta: U2FsdGVkX19RmbC8+CD60m7P/W67YS4A7WPiZIn+vOLfJT/xznrcNNdaw7TWEAIsVkSCzpXOmfZC12SI2P4tXCJCdjSVkYKdAMSbfOoLUVh3lLaAx2tIUWHfZW7yAvS6LDwa4qpwcRqdReN55ggguRwpSRv0NHErv2FGYQ7AwA7z+a3SR7M3IGAfG7f8TDAOW8ejJdVQVonQU8JKWvF03EYepI2Msnq3ImsV3r0SvZIztYkM/Iu+mDZ1Caz/soQeJQU33FuPpoq7agLPxwkg6Gis5uHGpbPrnPaWwVwVesFbn5KT7o6g2JjOhvx0v2U9H0FNwwSGYtAlOGNWsfvKA1T81a7iNlMtCaQm3HvQrhd3OprxRMmLznleABKtSy7+MVo0uH4WlT7VxGBBjQBL7Xl8TL1KxLSadUApvvkHphKhopdPpwESpbL24rm2VOfhHkHToN4/rUn/bcEkJ65VEts5opa+H2+jwPgyns8LS2BQuRh/7ujc2Y7DT2tt/KMjx+EHyKW5qFwiwKfB5tQfefwZMu4ZEZoexj1lLfOQ6UrNtDqVBdyKrXnUuDHso+9DG+uD87G6n8gcUk+y01MVywzUXCGbHOUL5+WwFzZlVd1xV4wlXzY41FwxSsvMX8rpKv+22s5dSlN40r6VzuK+AUXs61Q0iOynNjU0cNNWX95I9XA3ETI3pQsQ2IZ4HwUrgL+YosuqNg9Qx94ZWT3PKFRrQ0N36uj8MJGYZU/s5sMlx2xlCGl4M4cH8+BwfA+ka1y9zjCuvJaHzlAKa0fVnX8XjotErPwQ6UgGZDBlFJuAzF07WfVNfceyKKaoYW6uic423dLJ6MHVhzcXvNc1VW+3k/4dm2bGjDM97cwIgVTMHKJbh44JoOxTR3aneTHWEM2lEObGm4zEU3EtNbnUUKE0Q6czLjJAVwnva3mradl4MJHw+IF8CL5D3ttJdZeQRMFz+4iVksF5bZHPv20 EqvhB1eR yTS7OQWw6uxVFW6ZbvXmKllxs5Q7WE+++e0GRacy2/qgJF40B2z8m/cwH9SyYtX1YDm3slGkjlUs8FdLz80q7yop9s38sXf6MkkBMAy/h/M9U3/VmCnFPhenQuWG3QHHpP7dWts4h3R8e13WxFqoo/1d37jhCEgRU2ktggKARDmDNrmQs6zZxQ3LkYL9mZHqGILw9CEUtn8mClPF43GIPYqhGhJCiTBVodWbEwyDlsPZcMLCxyx+cDWfg54EhlYd0zuq5rnOxxSbDBy5n/eDQa+q7KRi3Hr04eGMWtqqJQWgMga6wcsORYsxxNIUh+CZCiHbnYN66MDYp3p0wwzt22PbLodkH840QD89+wmbZz1yvC2A/cVtt8bEv2x9RhZkBN76XL+ZMjFha8jc= 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 Thu, 22 May 2025 at 09:15, David Hildenbrand wrote: > > On 22.05.25 09:46, Fuad Tabba wrote: > > Hi David, > > > > On Thu, 22 May 2025 at 08:16, David Hildenbrand wrote: > >> > >> > >>>>> + * shared (i.e., non-CoCo VMs). > >>>>> + */ > >>>>> static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > >>>>> { > >>>>> - return IS_ENABLED(CONFIG_KVM_GMEM) && > >>>>> - kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE; > >>>>> + struct kvm_memory_slot *slot; > >>>>> + > >>>>> + if (!IS_ENABLED(CONFIG_KVM_GMEM)) > >>>>> + return false; > >>>>> + > >>>>> + slot = gfn_to_memslot(kvm, gfn); > >>>>> + if (kvm_slot_has_gmem(slot) && kvm_gmem_memslot_supports_shared(slot)) { > >>>>> + /* > >>>>> + * For now, memslots only support in-place shared memory if the > >>>>> + * host is allowed to mmap memory (i.e., non-Coco VMs). > >>>>> + */ > >>>> > >>>> Not accurate: there is no in-place conversion support in this series, > >>>> because there is no such itnerface. So the reason is that all memory is > >>>> shared for there VM types? > >>>> > >>> > >>> True that there's no in-place conversion yet. > >>> > >>> In this patch series, guest_memfd memslots support shared memory only > >>> for specific VM types (on x86, that would be KVM_X86_DEFAULT_VM and > >>> KVM_X86_SW_PROTECTED_VMs). > >>> > >>> How about this wording: > >>> > >>> Without conversion support, if the guest_memfd memslot supports shared > >>> memory, all memory must be used as not private (implicitly shared). > >>> > >> > >> LGTM > >> > >>>>> + return false; > >>>>> + } > >>>>> + > >>>>> + return kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE; > >>>>> } > >>>>> #else > >>>>> static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > >>>>> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c > >>>>> index 2f499021df66..fe0245335c96 100644 > >>>>> --- a/virt/kvm/guest_memfd.c > >>>>> +++ b/virt/kvm/guest_memfd.c > >>>>> @@ -388,6 +388,23 @@ static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma) > >>>>> > >>>>> return 0; > >>>>> } > >>>>> + > >>>>> +bool kvm_gmem_memslot_supports_shared(const struct kvm_memory_slot *slot) > >>>>> +{ > >>>>> + struct file *file; > >>>>> + bool ret; > >>>>> + > >>>>> + file = kvm_gmem_get_file((struct kvm_memory_slot *)slot); > >>>>> + if (!file) > >>>>> + return false; > >>>>> + > >>>>> + ret = kvm_gmem_supports_shared(file_inode(file)); > >>>>> + > >>>>> + fput(file); > >>>>> + return ret; > >>>> > >>>> Would it make sense to cache that information in the memslot, to avoid > >>>> the get/put? > >>>> > >>>> We could simply cache when creating the memslot I guess. > >>>> > >>> > >>> When I wrote it I was assuming that to ensure correctness we should > >>> check with guest memfd, like what if someone closed the gmem file in the > >>> middle of the fault path? > >>> > >>> But I guess after the discussion at the last call, since the faulting > >>> process is long and racy, if this check passed and we go to guest memfd > >>> and the file was closed, it would just fail so I guess caching is fine. > >> > >> Yes, that would be my assumption. I mean, we also msut make sure that if > >> the user does something stupid like that, that we won't trigger other > >> undesired code paths (like, suddenly the guest_memfd being !shared). > >> > >>> > >>>> As an alternative ... could we simple get/put when managing the memslot? > >>> > >>> What does a simple get/put mean here? > >> > >> s/simple/simply/ > >> > >> So when we create the memslot, we'd perform the get, and when we destroy > >> the memslot, we'd do the put. > >> > >> Just an idea. > > > > I'm not sure we can do that. The comment in kvm_gmem_bind() on > > dropping the reference to the file explains why: > > https://elixir.bootlin.com/linux/v6.14.7/source/virt/kvm/guest_memfd.c#L526 > > Right, although it is rather suboptimal; we have to constantly get/put > the file, even in kvm_gmem_get_pfn() right now. > > Repeatedly two atomics and a bunch of checks ... for something a sane > use case should never trigger. > > Anyhow, that's probably something to optimize also for > kvm_gmem_get_pfn() later on? Of course, the caching here is rather > straight forward. Done. Thanks, /fuad > -- > Cheers, > > David / dhildenb >