From: Deborah Brouwer <deborah.brouwer@collabora.com>
To: Ke Sun <sunke@kylinos.cn>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Tamir Duberstein" <tamird@kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Onur Özkan" <work@onurozkan.dev>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Lyude Paul" <lyude@redhat.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Sami Tolvanen" <samitolvanen@google.com>,
rust-for-linux@vger.kernel.org, linux-mm@kvack.org,
dri-devel@lists.freedesktop.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org, "Alvin Sun" <alvin.sun@linux.dev>
Subject: Re: [PATCH v4 04/11] drm/tyr: add per-file VM pool
Date: Wed, 21 Oct 2026 15:59:34 -0700 [thread overview]
Message-ID: <atlD1jzWqQhKE3w5@um790> (raw)
In-Reply-To: <20261020-tyr-ioctls-v4-4-704de77da223@kylinos.cn>
On Tue, Oct 20, 2026 at 04:25:21PM +0800, Ke Sun wrote:
> From: Alvin Sun <alvin.sun@linux.dev>
>
> Userspace needs multiple independent GPU address spaces per file,
> addressed by ID through the VM ioctls as in panthor. Store them in an
> IdPool (capped at 32 for panthor parity) plus an XArray. On a failed
> insertion the caller tears the VM down through the returned error, so
> an aborted creation never leaks a VM. The pool kills every VM still
> stored when the file closes.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
> ---
> drivers/gpu/drm/tyr/vm.rs | 138 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 137 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tyr/vm.rs b/drivers/gpu/drm/tyr/vm.rs
> index c5e307b1e2416..6935e4db667b9 100644
> --- a/drivers/gpu/drm/tyr/vm.rs
> +++ b/drivers/gpu/drm/tyr/vm.rs
> @@ -33,6 +33,7 @@
> }, //
> },
> fmt,
> + id_pool::IdPool,
> impl_flags,
> io::PhysAddr,
> iommu::pgtable::{
> @@ -53,7 +54,11 @@
> ArcBorrow,
> Mutex, //
> },
> - uapi, //
> + uapi,
> + xarray::{
> + AllocKind,
> + XArray, //
> + }, //
> };
>
> use crate::{
> @@ -948,3 +953,134 @@ fn pt_unmap(dev: &Device, pt: &IoPageTable<'_, ARM64LPAES1>, range: Range<u64>)
>
> Ok(())
> }
> +
> +/// Maximum number of VMs a single file may hold, matching panthor's
> +/// `PANTHOR_MAX_VMS_PER_FILE`.
> +const MAX_VMS_PER_FILE: usize = 32;
> +
> +/// Per-open-file pool of VMs.
> +#[pin_data(PinnedDrop)]
> +pub(crate) struct VmPool<'drm> {
> + /// Parent device, for error reporting.
> + dev: &'drm Device<Bound>,
> + #[pin]
> + ids: Mutex<IdPool>,
> + #[pin]
> + vms: XArray<Arc<Vm<'drm>>>,
> +}
> +
> +/// Error returned when a VM cannot be added to the pool. The caller
> +/// owns the teardown of the VM in [`AddError::vm`].
> +pub(crate) struct AddError<'drm> {
> + pub(crate) error: Error,
> + pub(crate) vm: Arc<Vm<'drm>>,
> +}
When I try to compile just this patch i get an error about
this being unused so better annotate it with #[expect(dead_code)]
like the others.
> +
> +impl<'drm> VmPool<'drm> {
> + /// Creates a new [`VmPool`].
> + #[expect(dead_code)]
> + pub(crate) fn new(dev: &'drm Device<Bound>) -> impl PinInit<Self> {
> + let ids = IdPool::new();
> + pin_init!(Self {
> + dev,
> + ids <- new_mutex!(ids),
> + vms <- XArray::new(AllocKind::Alloc),
> + })
> + }
> +
> + /// Stores the VM and returns the allocated ID.
> + ///
> + /// On failure - ID space exhausted or a store failure - the VM is
> + /// returned in an [`AddError`] so the caller owns the teardown.
> + // TODO: allocate IDs with the XArray directly (once it grows range
> + // allocation, the equivalent of C's `XA_LIMIT`) and drop the IdPool.
> + #[expect(dead_code)]
> + pub(crate) fn add(&self, vm: Arc<Vm<'drm>>) -> Result<u32, AddError<'drm>> {
> + let id = (|| {
> + let mut ids = self.ids.lock();
> + let unused = ids.find_unused_id(1).ok_or(ENOSPC)?;
> + if unused.as_usize() > MAX_VMS_PER_FILE {
> + return Err(ENOSPC);
> + }
> + Ok(unused.acquire())
> + })();
> + let id = match id {
> + Ok(id) => id,
> + Err(error) => return Err(AddError { error, vm }),
> + };
> +
> + let mut vms = self.vms.lock();
> + match vms.store(id, vm, GFP_KERNEL) {
> + Ok(prev_vm) => {
> + if let Some(prev_vm) = prev_vm {
> + // An existing VM at the freshly allocated slot means the
> + // IdPool and the XArray are out of sync: the stored VM is
> + // a pool entry, so the pool kills it and the caller's VM
> + // is handed back for the caller to kill.
> + let stored = vms.remove(id);
> + drop(vms);
> + prev_vm.kill();
> + self.ids.lock().release_id(id);
> + dev_err!(
> + self.dev,
> + "IdPool/XArray out of sync at VM pool id {id} (stored VM conflict)"
> + );
> + return Err(AddError {
> + error: EBUSY,
> + vm: stored.expect("VM was just stored"),
Since the rust for linux coding guidlines say:
panicking should be very rare and used only with a good reason.
In almost all cases, a fallible approach should be used, typically returning a Result.
I'm wondering if there is a way to avoid this expect().
For example, you could store a vm.clone() in the xarray and keep the vm
that was passed to this function so that it can be returned on error.
And on success, the vm would just drop so the overall ref count wouldn't
be incremented.
> + });
> + }
> + Ok(id as u32)
> + }
> + Err(err) => {
> + // Drop the XArray spinlock before acquiring the `ids` mutex.
> + drop(vms);
> + // Release the pooled id; the VM never entered the pool, so it
> + // is returned to the caller for teardown.
> + self.ids.lock().release_id(id);
> + Err(AddError { error: err.error, vm: err.value })
When i run rustfmt on this patch it reformats this line, can you double
check you ran rustfmt?
> + }
> + }
> + }
> +
> + /// Removes and kills the VM with the given ID.
> + #[expect(dead_code)]
> + pub(crate) fn remove(&self, id: u32) -> Result<()> {
> + let mut vms = self.vms.lock();
> + let vm = match vms.remove(id as usize) {
> + Some(vm) => vm,
> + None => return Err(EINVAL),
> + };
> + // Drop the XArray spinlock before killing, since `kill()` may sleep.
> + drop(vms);
> + // Kill the VM before handing the id back to the pool, so a VM is
> + // never reusable while still alive.
> + vm.kill();
> + self.ids.lock().release_id(id as usize);
Since i just learned about this myself, I should mention that you can
now use num::casts::FromSafeCast and then write
usize::from_safe_cast(id).
> + Ok(())
> + }
> +
> + /// Gets a shared reference to the VM with the given ID.
> + #[expect(dead_code)]
> + pub(crate) fn get(&self, id: u32) -> Option<Arc<Vm<'drm>>> {
> + let vms = self.vms.lock();
> + let borrow = vms.get(id as usize)?;
> + Some(Arc::from(borrow))
> + }
> +}
> +
> +#[pinned_drop]
> +impl PinnedDrop for VmPool<'_> {
> + fn drop(self: Pin<&mut Self>) {
> + let this = self.project();
I don't think you need to project the VmPool here because we only
need a shared ref to the pool, and the vms guard gives us the interior
mutability we need to modify the xarray anyway.
> + // Kill every VM left in the pool. The ID range is bounded by
> + // `MAX_VMS_PER_FILE`, so this loop is cheap and runs at file close.
> + for id in 1..=MAX_VMS_PER_FILE {
> + // Release the XArray lock guard before killing: `kill()` may sleep.
> + let vm = this.vms.lock().remove(id);
> + if let Some(vm) = vm {
> + vm.kill();
> + }
> + }
> + }
> +}
>
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-10-21 23:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 8:25 [PATCH v4 00/11] drm/tyr: add VM and BO ioctl support Ke Sun via B4 Relay
2026-10-20 8:25 ` [PATCH v4 01/11] rust: sizes: add SZ_4G constant Ke Sun via B4 Relay
2026-10-20 8:25 ` [PATCH v4 02/11] rust: mm: add `task_size` helper Ke Sun via B4 Relay
2026-10-20 8:25 ` [PATCH v4 03/11] rust: sync: arc: relax `ForeignOwnable` for `Arc<T>` Ke Sun via B4 Relay
2026-10-20 8:25 ` [PATCH v4 04/11] drm/tyr: add per-file VM pool Ke Sun via B4 Relay
2026-10-21 22:59 ` Deborah Brouwer [this message]
2026-10-20 8:25 ` [PATCH v4 05/11] drm/tyr: add user and MCU VM specifications Ke Sun via B4 Relay
2026-10-20 8:25 ` [PATCH v4 06/11] drm/tyr: add BO creation and lookup helpers Ke Sun via B4 Relay
2026-10-20 8:25 ` [PATCH v4 07/11] drm/tyr: add VM-related ioctls Ke Sun via B4 Relay
2026-10-20 8:25 ` [PATCH v4 08/11] drm/tyr: add BO-related ioctls Ke Sun via B4 Relay
2026-10-20 8:25 ` [PATCH v4 09/11] rust: device: expose the device DMA attribute Ke Sun via B4 Relay
2026-10-20 8:25 ` [PATCH v4 10/11] drm/tyr: gem: flush write-combine BOs from probe-time coherence Ke Sun via B4 Relay
2026-10-20 8:25 ` [PATCH v4 11/11] drm/tyr: gem: map cached BOs for DRM_PANTHOR_BO_WB_MMAP Ke Sun via B4 Relay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atlD1jzWqQhKE3w5@um790 \
--to=deborah.brouwer@collabora.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=alvin.sun@linux.dev \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=driver-core@lists.linux.dev \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=simona@ffwll.ch \
--cc=sunke@kylinos.cn \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=work@onurozkan.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®