From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) (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 E5B02434E5F for ; Thu, 27 Aug 2026 19:08:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787857690; cv=none; b=MA21H3KQyc4lREMys4pufL/3pqxkbKHQ6bh6bUeqeyI00LKVoSR1q8hY748WKADLUUDLneMcQqUxn1bGnpb5D3eMypY/2KdeA+7/28+YLAe/FMBda5CHLjkGCqPn7xlC2OBG9e5eiTHS3azEToc22MnxmRgNpy6um0Zw4WG6q/M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787857690; c=relaxed/simple; bh=YAu1i5AWtB/mdPrcibBFB5fs0b8x5YEB+6wjvbVTug4=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Gk/VXp3YPa3Vyg/WC43VWB/IamKmBxfFkYYoS2LqDktdUIECbzSmRpdyeSacf58YUnWF4izRIlFQ6OZg+kSPQQlkjrqDaO0BGNlZiRnqIO6j/pXxDcXJW6TBWsxGWvlQKH2HkC9jdyHQEhIsC2OSRozFjPWn36T3ojwIWz/SYdc= 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=QXhanJ+k; arc=none smtp.client-ip=209.85.214.199 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="QXhanJ+k" Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-2cee1ec30f2so1639915ad.3 for ; Thu, 27 Aug 2026 12:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1787857687; x=1788462487; darn=lists.linux.dev; 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=JWGZwnfyNQRYCnM1UqJIynPGxtHIQDoEVfaq/bKW7II=; b=QXhanJ+kgVlAyjRTPcT7z4UCUffKnyF1hevuE+7C7OL85FY7SbdS1y0yJVvNOy9n0d M13EYd5Ivyx8WJaafheVponCIvdzxUUWC6ny5mzKCHuHpZwmm92Smioi8PdEW7X8MthU ndc8+u5Wga51+5OmnHhJCBO28Oq0tG9CdbfySEbbY5/pkOKZIgQG/asV8pKbHvOtC79w Gng9YQ87M2WH8QU2m2hUD+DPFIhtGIy5CHC0fF4KdtWJkBK1+zKiqIEQnF5sNGwAw8+G DnreRd7hrTJyVlVLBP1iQQ2FG3KgcAJhd2xVONl+8YEGDDXB+FQN3T65HP9MBe2RKq5T mIIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787857687; x=1788462487; 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=JWGZwnfyNQRYCnM1UqJIynPGxtHIQDoEVfaq/bKW7II=; b=B9N2ZU6cfpEE7CzOLb1CB/FXMdQZnYd0H1rn4EDgnreO2uWitMgaIvyRLir3r+jI3z 5Y7f1hgHhOKgdofqN8iTMciMZM2xsso673ieEv1cyTPJN90jiqzVa92aE26JfswRChLr CwpEGBprS359JDlQJVEIrIgcRe76IS2sZclGoA6Onn3UU6eO4MogClJaeS0xhY7TmSzE pZChxNwBIQMT9DY/hf+7vRzbii/GtwBbhPilMhpsPXmMM1ls/883gulrZdJ2vW6sUd8i S6aunGjSoMtQ3nQjMQa9zsSuua9k3qwDwrqA3AEUu2ZQ3chAokcWa8G1+LuLB2Xg8IO7 60kw== X-Forwarded-Encrypted: i=1; AHgh+RoSwF0H89Ylkn5uxzuEa+PfFmy9dP8EGM91sTcKeVb/Q2VrIK0zhooG+7lj/QfdtAtHJMzDtcniwTk4@lists.linux.dev X-Gm-Message-State: AFuF++nGjBYpuYgvpkSi+zbAegyojxQ3iT6b2uXgGWx72y0VjNh9HLGS Vd/N6jje61miuypkY1LFPZ5pwZRn8aQFkNA6dW6CIaToTtMH8AF09Tu1kURqOPWCJsPsvsVWdug eXE/hxQ== X-Received: from plblq15.prod.google.com ([2002:a17:903:144f:b0:2d6:e58f:8e81]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:15cf:b0:2d7:1aeb:739 with SMTP id d9443c01a7336-2d74e1295c2mr19606415ad.13.1787857686248; Thu, 27 Aug 2026 12:08:06 -0700 (PDT) Date: Thu, 27 Aug 2026 12:08:05 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <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: Xiaoyao Li Cc: Ackerley Tng , 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 Thu, Aug 27, 2026, Xiaoyao Li wrote: > On 8/26/2026 9:53 PM, Sean Christopherson wrote: > > > > 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. > > Side topic. > > If KVM enforces KVM_MEMSLOT_GMEM_ONLY when gmem_in_place_conversion is true > like below proposal, should we update KVM's guest memory accessors to access > gmem directly? No, because routing KVM accesses through uaccess means we just have to ensure PRIVATE memory isn't mapped into userspace, which we already have to do anyways. Now, that doesn't preclude future work from optimizing certain flows to avoid GUP, or to harden KVM in other ways. But as a first step, bypassing uaccess is actively dangerous. > If still use the existing code of accessing userspace_addr of the memslot, I > think KVM needs to document clearly that when > KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES is enumerated, if configuring the > guest_memfd for a memslot, the userspace_addr passed in needs to be the > mmaped address of the guest_memfd. Ya. > > 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; > > I like this idea. It makes gmem_in_place_conversion a step closer to what > its name implies, though in-place conversion is not truly 100% > guaranteed[*]. > > [*] https://lore.kernel.org/all/akUbz_kJvYulaboo@google.com