From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B266439909 for ; Wed, 26 Aug 2026 13:53:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.198 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787752406; cv=none; b=kYcA9hcOy2x+ooOpFL1TlwupvkHPtCsHGEqQUa+dlyqalUF8KFpfEHfOnkWM1QgbAW86j7P5crlgG3lP3RhhjJ2VipixcASvVNxFKVhWBKzoZUsHWQrsNjI8IP9v3+r502QkfzblXgs6bQVr/ckKkhl+l/wCXXokC2Q63rk9XSg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787752406; c=relaxed/simple; bh=aKI/UKGte84OVTfWfIAvvMaWsDxT45eGHGOViohEC78=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=GJHluuB6Hx4Pw4hBz9FAe7rfFRX4Cn4Olj7Ff1qzec6hSED4ERZFM3odTHhI1iCagEz7sAuslw7UNyqf+0UVA1/a/3KYwniwoNMnaauYhtFXzf8OcSnH0RMVpHHszlc4iqXV3Sy75lZOh4XXrxt1quis7FKTviu4gDutCuMluWE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Fw9M22+/; arc=none smtp.client-ip=209.85.214.198 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Fw9M22+/" Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2d6df0a1e18so14071185ad.1 for ; Wed, 26 Aug 2026 06:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1787752391; x=1788357191; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=njsQrhr1Rw86G3MMqhXpdm0dYelYnqk43kJ0tkWzOHc=; b=Fw9M22+/3+Tuh6ZV/JJEkAFj+RlBK2Q9Is5LYK1aJGSvAYYPdH8byGaD9gmmbxiezq Pws3Ue36HCIptbD8j+oui5RPC+ySOg8GWSwO11fCaJQ++8OhIgiyozKW0Jwj4/bR5ad8 15VmAThVs+G8fUQ8R8c/4a4RIqKteUfeRkW1pChn7iLi4mIjVIPbrFZ03L89l+8rNdbF U+sVGh++kCaYC0e0vCVvSoCRsYBYAIEd4Z0mu+N89q/NYltvTvhPE3T7Audf8zSnNxeP 7D22SHuL+0zRKUoYVrojsO/83fUXSG5UXu+PgNEFV0uKGVQ8aaEqbMs2mH8eojYT2Dle j6Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787752391; x=1788357191; h=content-type: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:content-type; bh=njsQrhr1Rw86G3MMqhXpdm0dYelYnqk43kJ0tkWzOHc=; b=CKzxHYstceEvQWMcy7YD1cnnz3PTUnnk2Tse0divQfrx4P7MRzoMmG0RqYEKiM95qo dkHdprJ3pHvAxmM17u1fvY//o6YQS/zWD5F1KMGs/nT7igkgHrYhYWglmj5Eh/n0b5Xc anjGD7zxQdmQWTcJS5E0cd/GBSS1Vr80KtiMmxEBskiPwf/lsX60P/NDY0XszpFyNKO4 Z/YzY1Swt0cMBVYdD0hmBn0iONIdMwGPKNFIXx1FjF8vwGK0xfhcdjr4tbHrL8HqSheV 6k9Mew6rNJ9dWgoHVtUtnbxozPmksnUOKYshkPIXvusrPaug2AMphhu7xOJuQzCmwVKi ytrQ== X-Forwarded-Encrypted: i=1; AHgh+RotOmgOhYYpsU/FY9VN9JnVo6dGLY9Ucin95mVHEz5qmrlmp6+kEU6k0A32wigrkoxQ3Zs=@vger.kernel.org X-Gm-Message-State: AFuF++kWc9dQU+ukqEqLHolhnmr/rahhAPyuQSgHStG7bZzsZVdBOTCr k3Y3JDp3+mrGte/0WOPbNkx+qV2oz7EMoU1ot/6yJRWt81SdHzSGriiY1SyOor/2bTRiSByjcLs RpqIhzQ== X-Received: from plnn1.prod.google.com ([2002:a17:902:d0c1:b0:2c8:1ded:d061]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:c40a:b0:2d7:1bfd:b240 with SMTP id d9443c01a7336-2d71bfdb766mr27401015ad.4.1787752388141; Wed, 26 Aug 2026 06:53:08 -0700 (PDT) Date: Wed, 26 Aug 2026 06:53:07 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260807-gmem-inplace-conversion-v10-9-2fc18ee6d3ba@google.com> <13ca60c6-e154-4397-8092-09f861e90fe0@kernel.org> <7eba513d-cdae-4832-abac-038dcdd88517@intel.com> Message-ID: Subject: Re: [PATCH v10 09/41] KVM: guest_memfd: Filter both shared and private when invalidating From: Sean Christopherson To: Ackerley Tng Cc: Xiaoyao Li , Michael Roth , Suzuki K Poulose , "David Hildenbrand (Arm)" , aik@amd.com, andrew.jones@linux.dev, binbin.wu@linux.intel.com, brauner@kernel.org, chao.p.peng@linux.intel.com, jmattson@google.com, jthoughton@google.com, oupton@kernel.org, pankaj.gupta@amd.com, qperret@google.com, rick.p.edgecombe@intel.com, rientjes@google.com, shivankg@amd.com, steven.price@arm.com, tabba@google.com, willy@infradead.org, wyihan@google.com, yan.y.zhao@intel.com, forkloop@google.com, pratyush@kernel.org, aneesh.kumar@kernel.org, liam@infradead.org, Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Jonathan Corbet , Shuah Khan , Shuah Khan , Vishal Annapurve , Andrew Morton , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Youngjun Park , Qi Zheng , Shakeel Butt , Kiryl Shutsemau , Baoquan He , Jason Gunthorpe , John Hubbard , Peter Xu , tarunsahu@google.com, Vlastimil Babka , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev Content-Type: text/plain; charset="us-ascii" On Wed, Aug 26, 2026, Ackerley Tng wrote: > Xiaoyao Li writes: > > > On 8/26/2026 2:55 AM, Sean Christopherson wrote: > >> On Tue, Aug 25, 2026, Michael Roth wrote: > >>> On Wed, Aug 26, 2026 at 12:13:47AM +0800, Xiaoyao Li wrote: > >>>> On 8/20/2026 9:32 AM, Sean Christopherson wrote: > >>>>> And vice versa, a PUNCH_HOLE on a SHARED gmem (if userspace is > >>>>> using an INIT_SHARED gmem for the shared branch of a memslot) could invalidate the > >>>>> PRIVATE mappings (of a different gmem instance). > >>>> > >>>> I'm wondering now how this could happen. > >>>> > >>>> the requirement for PUNCH_HOLE on gmem to trigger mapping invalidation is > >>>> the gmem is bound with the memslot. But how can a memslot bound with two > >>>> gmem instances? > >>> > >>> I think this is for when userspace uses an mmap'able guest_memfd instance > >>> to handle shared memory, and a 'normal' guest_memfd instance for private > >>> memory. Each instance is bound to the same memslot/GPA range, and > >>> KVM_SET_MEMORY_ATTRIBUTES handles switching between the 2. > > > > What I didn't figure out is exactly how the two gmem instances are bound > > to the same memslot. > > > > The case I can imagine is > > > > 1. create gmem1 with GUEST_MEMFD_FLAG_MMAP and > > GUEST_MEMFD_FLAG_INIT_SHARED, and get fd1. mmap the returned fd1 to get > > a hva. > > > > 2. create gmem2 to get a fd2. > > > > 3. call KVM_SET_USER_MEMORY_REGION2 with KVM_MEM_GUEST_MEMFD flag. Pass > > the @hva from 1) to 'userspace_addr' field and pass the gmem fd2 to > > 'guest_memfd' field. > > > > However, with this case, only gmem2 is bound to the memslot while gmem1 > > is not. Following PUNCH_HOLE on gmem1 doesn't invalidate any mappings > > because the f->bindings of it is empty. > > > > Do I miss anything? Oh, I misread your question. You were specifically asking about a PUNCH_HOLE in a SHARED gmem instance over-invalidating PRIVATE mappings. You're right, that wouldn't happen because the invalidations would come in via mmu_notifiers, not from KVM. > I think Xiaoyao is right about this, the "vice versa" part is wrong, Ya. > Is this just a case of user error? That with gmem_in_place_conversion, > userspace should not use userspace_addr from something other than the > gmem for the same memslot? Yes. It's not just invalidations that will go sideways, KVM accesses to guest memory won't hit the same physical page as actual guest accesses. Huh. But that isn't strictly guaranteed, because userspace could bind to a memslot that isn't configured with GUEST_MEMFD_FLAG_MMAP, in which case SHARED faults will go through the VMA, not kvm_mmu_faultin_pfn_gmem(). It's a bit early in the morning, but off the top of my head, I can't think of any reason we need to support such a setup. If userspace really, really wants to use a separate mapping, they could DELETE+CREATE an equivalent memslot without the guest_memfd file descriptor. So I think we should do this? diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 9c2d52bdf25e..86f53e53a136 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -1013,7 +1013,7 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot, */ WRITE_ONCE(slot->gmem.file, file); slot->gmem.pgoff = start; - if (kvm_gmem_supports_mmap(inode)) + if (gmem_in_place_conversion || kvm_gmem_supports_mmap(inode)) slot->flags |= KVM_MEMSLOT_GMEM_ONLY; xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL); Regardless, the key aspect of all this is that in-place conversion is brand new functionality, so we don't have to ensure backwards compatibility.