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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 60B7AE6689E for ; Sat, 20 Dec 2025 10:05:39 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1F36B10E222; Sat, 20 Dec 2025 10:05:39 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.b="Fq214dmH"; dkim-atps=neutral Received: from mail-ej1-f74.google.com (mail-ej1-f74.google.com [209.85.218.74]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7289510E222 for ; Sat, 20 Dec 2025 10:05:38 +0000 (UTC) Received: by mail-ej1-f74.google.com with SMTP id a640c23a62f3a-b7a29e6f9a0so332284466b.1 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=lists.freedesktop.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=Fq214dmHve4crsGTs5FRs/zXb/FV56KVjA5g/kL+O6HjMcsYjVcDoXEvH9NUpSYPUe pdPJwI14yEmYw+qrLpxPBTpYk3YctXWmwcrXVBrQmwtpeF4c44MxO+6fAlN4zKvA6kvz 1kx5mF0FC4lFfRFQqfuCWZX9aPT/WqUU2svyuZzB7yyGNhRdlwSQOTx6wQI3tF9nRkmc vxbAezIp0TY7TIgvMbB7LMPFfXWtqx2jyzoeWZRyG88nwiopyuSq5TmUbSxX87b9rBRj uijT7s6Ciq1XEtU1JRBpzpWsC6Vw1jpLPRFoMtam0jN2iszZ15uVMUSBdT9sN7IDBUGp R+Ng== 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=DKJvErVJRw4pSuRkp2LssrakTBHIHMIide8JwwyGaif0Qsux1NC/qiuoIWUKjhzZ9o 15WnvJ0CD3aW0A2G04YG6mB0kK1r+Vj9f6a0gpioynLUEBXcfkPNOoAb2to04Q/F8cy4 H5oYDgr+A0M2GnpJ6IPn+tfI+sjrrndgHNlTQhNXzPyeeKZiuLkBHqXI03CyFPD3kbOV mU+OoNldHQiwQn+bGz4ewkVCF+HXkLTTkmOA+v4Fcux8sTuvbYruR4G6m1Q10cGQU6m5 Op59cG0Pmqh1LtU4/krZsdIHtWqxqcC1wD/dWQUMpMr8rBMKEWOru+Tk8Vh5KYbS9Z4/ EAUg== X-Forwarded-Encrypted: i=1; AJvYcCUtvVQidnqTUHWKGoQ89UaQTaf8rynDgJpU+JmTLgolpMMwwmz0YPKKmRrJODwx69zJQHiRHCu9qA==@lists.freedesktop.org X-Gm-Message-State: AOJu0YyUiwHzxDLQcf2eAs+2U4q3aYowDo5ZPtjPT6yBcUuX8/jOkiVk zJXfxXRSOoflq5B0JdQ36UyUC9WwT7fhzqjDnFRQW0zrLsDFmj23MGNj0SSfu2qYliTyZ4pE20m lS3BIoYwYLlu8z6Uzsg== 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: 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" X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" 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