From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f74.google.com (mail-ej1-f74.google.com [209.85.218.74]) (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 9DD472F99B8 for ; Sat, 20 Dec 2025 10:05:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766225140; cv=none; b=LibqA5uCxHpH3LBmEb56pCTK4Oom8isyJeGlSeLmL02wixtNQFumDZU0/ZVmqyw6JwTkk82POxbH8E2geCBCJoWhEHNr8aGqPvuPSMLTcIgO6RggWlCP48fOeWr4XmNXDdoEYelrBq08IIEgES1cCClSH3JTmpana5NixOMdkUE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766225140; c=relaxed/simple; bh=AeXXtz/xKBbgkU0M2gnK6yJRe3S7izp9ryLM1833MBs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=YRAqR+r1KOTK4zddOmq4Yvdxe2aYe1/l7oTAOflJuYrEA9FsB5L6tn/TSXVuKrmZHIJTGSDIQrQF8G3+bpa9fLEW0PhQbxJVWmCnzLM07EmMlnd/sInRz4PpuLM4SwnGSdNRBLIjvzQV/5sfNmwFs7oK15ZzSgi8qrp3PmUf8o0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=p/uP8rnm; arc=none smtp.client-ip=209.85.218.74 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--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="p/uP8rnm" Received: by mail-ej1-f74.google.com with SMTP id a640c23a62f3a-b801b94fedcso283804966b.2 for ; Sat, 20 Dec 2025 02:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1766225137; x=1766829937; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=+5We+jBO0+cCD3c++ROAWKy2uW8li7ctcnKyzh7ve8o=; b=p/uP8rnmekDhufC1a0igzGUxb9fqqBOmkxoNOnvqJgmb04K7j7mgED7YoOF7Mnqj/G fZ+yrefWHb9Aagy+gdvP6t4MmZw01AQGCzf1SaRc7/0A94ng733yr7LTNEL2BYdv9lsr Vp4bjlCauOTih4q51gLykZtGPnPHupohHlS0F+rwLoOKPD9F2A1vruXTUFHfDBj59bZ6 cNPE8i9blM32Fh15pN6SIiROpDL3ufp67bPbAPZlhmQ04tLLlG7P14ID19g7lqqdYajK Qld6cM1Ho+XfNd5HY2EA1+aVlGJeY3EwpcQi39NdxdFq+iZVAPTLP0iWSpiAMcWp2sAr utpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766225137; x=1766829937; h=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; bh=+5We+jBO0+cCD3c++ROAWKy2uW8li7ctcnKyzh7ve8o=; b=IzALHL87nckuB5PQILNBlkLgaLwGWDvItaGFoSSC0Mn7K0ULbKchRR/xIJoKSDw+9I dS+mC0V4MK0AIBmIg7ZTskuYhTpdJ9jx8J5xVd4Q7Kyfbm1rZRbT83b4/yDGmvmdcdCh 996y3w+NAkjm10jnciZ8w7EGs6npVBVqWs3cvDVyxp75EYzWitZ3voGQ55mR+pdG5sW4 sC39+2eQSTnqniXo8yq6aHZLrL4fQsiuGp0DiPMwz/meCgH8qJI3MaA8NMcVsKs1qmap 7dpjhOjIW7c0b/ewETb6FBFecflzbfs88R/KUEbaBNbnAuGbAaLOj8GshshL1U/9kqfY I90Q== X-Forwarded-Encrypted: i=1; AJvYcCXw8EKF6qdOs9baHSgtGP6fr87VhDzLsvnu34ONHZlXiWBVtCpe8QhSTvdx1JGeYTxKfDfvsrBkgVBnkQE=@vger.kernel.org X-Gm-Message-State: AOJu0YwUmc2BCwUCt8aa8ecmPZ9FUZDV5KKI1IIahtJKyYDvXkIjqhMS Lw/BPlqAGVfdlzV8E02N9lcB5VEEE1XbHrk77cNFnq32Md5UkGWsg0MfaJtNK8+JOZPyCEDr03W aWkoZDQNvxlwtRT31aw== X-Google-Smtp-Source: AGHT+IH+qbCL3E4KlR/xCuII76jDF4Kk0p12le+sQrE5wjNjdmbXoR9Ff184WWDRAFxJ6twYy7w7Nft4HG28DGY= X-Received: from edtn6.prod.google.com ([2002:aa7:db46:0:b0:64b:a192:b5]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a17:907:7814:b0:b80:4141:a470 with SMTP id a640c23a62f3a-b804141a5d5mr252551866b.6.1766225136958; Sat, 20 Dec 2025 02:05:36 -0800 (PST) Date: Sat, 20 Dec 2025 10:05:35 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251128-gpuvm-rust-v1-0-ebf66bf234e0@google.com> <20251128-gpuvm-rust-v1-4-ebf66bf234e0@google.com> Message-ID: Subject: Re: [PATCH 4/4] rust: drm: add GPUVM immediate mode abstraction From: Alice Ryhl To: Danilo Krummrich Cc: Daniel Almeida , Matthew Brost , "Thomas =?utf-8?Q?Hellstr=C3=B6m?=" , Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter , Boris Brezillon , Steven Price , Liviu Dudau , Miguel Ojeda , Boqun Feng , Gary Guo , "=?utf-8?B?QmrDtnJu?= Roy Baron" , Benno Lossin , Andreas Hindborg , Trevor Gross , Frank Binns , Matt Coster , Rob Clark , Dmitry Baryshkov , Abhinav Kumar , Sean Paul , Marijn Suijten , Lyude Paul , Lucas De Marchi , Rodrigo Vivi , Sumit Semwal , "Christian =?utf-8?B?S8O2bmln?=" , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, Asahi Lina Content-Type: text/plain; charset="utf-8" On Sat, Dec 20, 2025 at 09:48:17AM +0000, Alice Ryhl wrote: > On Fri, Dec 19, 2025 at 04:35:00PM +0100, Danilo Krummrich wrote: > > On Fri Nov 28, 2025 at 3:14 PM CET, Alice Ryhl wrote: > > > + /// Returns a [`GpuVmBoObtain`] for the provided GEM object. > > > + #[inline] > > > + pub fn obtain( > > > + &self, > > > + obj: &T::Object, > > > + data: impl PinInit, > > > + ) -> Result, AllocError> { > > > + Ok(GpuVmBoAlloc::new(self, obj, data)?.obtain()) > > > + } > > > > Does this method make sense? We usually preallocate a VM_BO, then enter the > > fence signalling critical path and then obtain the VM_BO. > > Hmm, but there is something tricky here. When do we add it to the extobj > list, then? If we add it before starting the critical path, then we must > also call drm_gpuvm_bo_obtain_prealloc() before starting the critical > path because obtain must happen before drm_gpuvm_bo_extobj_add(). And > adding it to extobj after signalling the fence seems error prone. > > And besides, adding it to the extobj list before the critical path > means that we can have drm_gpuvm_exec_lock() lock the new BO without > having to do anything special - it's simply in the extobj list by the > time we call drm_gpuvm_exec_lock(). > > > > +impl DerefMut for GpuVmCore { > > > + #[inline] > > > + fn deref_mut(&mut self) -> &mut T { > > > + // SAFETY: By the type invariants we may access `core`. > > > + unsafe { &mut *self.0.core.get() } > > > + } > > > +} > > > > Hm..it seems more natural to me to deref to &GpuVm and provide data() and > > data_mut(). > > That's fair. > > > > +impl Drop for GpuVmBoAlloc { > > > + #[inline] > > > + fn drop(&mut self) { > > > + // SAFETY: It's safe to perform a deferred put in any context. > > > + unsafe { bindings::drm_gpuvm_bo_put_deferred(self.as_raw()) }; > > > > This does not need to be deferred, no? > > I think what I *actually* want to call here is > > kref_put(&self->kref, drm_gpuvm_bo_destroy_not_in_lists_kref); > > like what drm_gpuvm_bo_obtain_prealloc() does as of the first patch in > this series. > > > > + } > > > +} > > > + > > > +/// A [`GpuVmBo`] object in the GEM list. > > > +/// > > > +/// # Invariants > > > +/// > > > +/// Points at a `drm_gpuvm_bo` that contains a valid `T::VmBoData` and is present in the gem list. > > > +pub struct GpuVmBoObtain(NonNull>); > > > > How is this different from GpuVmBo? The only object that is not in the GEM list > > should be GpuVmBoAlloc, i.e. the preallocated one. > > The difference is whether there is pointer indirection or not. > > This type is morally an ARef>, except I don't expose any way > to increment the refcount. > > Alice