From: Demi Marie Obenour <demiobenour@gmail.com>
To: dri-devel@lists.freedesktop.org,
Xen developer discussion <xen-devel@lists.xenproject.org>,
linux-media@vger.kernel.org
Cc: "Val Packett" <val@invisiblethingslab.com>,
"Christian König" <christian.koenig@amd.com>,
"Suwit Semal" <sumit.semwal@linaro.org>
Subject: Pinned, non-revocable mappings of VRAM: will bad things happen?
Date: Wed, 15 Apr 2026 19:27:40 -0400 [thread overview]
Message-ID: <a06133f7-3093-4733-9786-bc46c1453e06@gmail.com> (raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 862 bytes --]
Is it safe to assume that if a dmabuf exporter cannot handle
non-revocable, pinned importers, it will fail the import? Or is
using dma_buf_pin() unsafe if one does not know the exporter?
For context, Xen grant tables do not support revocation. One can ask
the guest to unmap the grants, but if the guest doesn't obey the only
recourse is to ungracefully kill it. They also do not support page
faults, so the pages must be pinned. Right now, grant tables don't
support PCI BAR mappings, but that's fixable.
How badly is this going to break with dGPU VRAM, if at all? I know
that AMDGPU has a fallback when the BAR isn't mappable. What about
other drivers? Supporting page faults the way KVM does is going to
be extremely hard, so pinned mappings and DMA transfers are vastly
preferable.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2026-04-15 23:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 23:27 Demi Marie Obenour [this message]
2026-04-16 9:57 ` Pinned, non-revocable mappings of VRAM: will bad things happen? Christian König
2026-04-16 16:13 ` Demi Marie Obenour
2026-04-17 7:53 ` Christian König
2026-04-17 19:35 ` Demi Marie Obenour
2026-04-20 8:49 ` Christian König
2026-04-20 17:03 ` Demi Marie Obenour
2026-04-20 17:58 ` Christian König
2026-04-20 18:46 ` Demi Marie Obenour
2026-04-20 18:53 ` Christian König
2026-04-20 19:12 ` Demi Marie Obenour
2026-04-21 16:55 ` Val Packett
2026-04-21 17:43 ` Christian König
2026-04-22 1:27 ` Demi Marie Obenour
2026-04-22 2:03 ` Alex Deucher
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=a06133f7-3093-4733-9786-bc46c1453e06@gmail.com \
--to=demiobenour@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-media@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=val@invisiblethingslab.com \
--cc=xen-devel@lists.xenproject.org \
/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