From: Demi Marie Obenour <demiobenour@gmail.com>
To: Honglei Huang <honglei1.huang@amd.com>,
Huang Rui <ray.huang@amd.com>,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
Dmitry Osipenko <dmitry.osipenko@collabora.com>,
dri-devel@lists.freedesktop.org,
David Airlie <airlied@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Gurchetan Singh <gurchetansingh@chromium.org>,
Chia-I Wu <olvaffe@gmail.com>,
Akihiko Odaki <akihiko.odaki@daynix.com>,
Lingshan Zhu <Lingshan.Zhu@amd.com>
Subject: Re: [RFC PATCH 3/3] drm/virtio: implement blob userptr resource object
Date: Sat, 21 Dec 2024 20:59:58 -0500 [thread overview]
Message-ID: <2fb36b50-4de2-4060-a4b7-54d221db8647@gmail.com> (raw)
In-Reply-To: <Z2WO2udH2zAEr6ln@phenom.ffwll.local>
On 12/20/24 10:35 AM, Simona Vetter wrote:
> On Fri, Dec 20, 2024 at 06:04:09PM +0800, Honglei Huang wrote:
>> From: Honglei Huang <Honglei1.Huang@amd.com>
>>
>> A virtio-gpu userptr is based on HMM notifier.
>> Used for let host access guest userspace memory and
>> notice the change of userspace memory.
>> This series patches are in very beginning state,
>> User space are pinned currently to ensure the host
>> device memory operations are correct.
>> The free and unmap operations for userspace can be
>> handled by MMU notifier this is a simple and basice
>> SVM feature for this series patches.
>> The physical PFNS update operations is splited into
>> two OPs in here. The evicted memories won't be used
>> anymore but remap into host again to achieve same
>> effect with hmm_rang_fault.
>
> So in my opinion there are two ways to implement userptr that make sense:
>
> - pinned userptr with pin_user_pages(FOLL_LONGTERM). there is not mmu
> notifier
>
> - unpinnned userptr where you entirely rely on userptr and do not hold any
> page references or page pins at all, for full SVM integration. This
> should use hmm_range_fault ideally, since that's the version that
> doesn't ever grab any page reference pins.
>
> All the in-between variants are imo really bad hacks, whether they hold a
> page reference or a temporary page pin (which seems to be what you're
> doing here). In much older kernels there was some justification for them,
> because strange stuff happened over fork(), but with FOLL_LONGTERM this is
> now all sorted out. So there's really only fully pinned, or true svm left
> as clean design choices imo.
>
> With that background, why does pin_user_pages(FOLL_LONGTERM) not work for
> you?
+1 on using FOLL_LONGTERM. Fully dynamic memory management has a huge cost
in complexity that pinning everything avoids. Furthermore, this avoids the
host having to take action in response to guest memory reclaim requests.
This avoids additional complexity (and thus attack surface) on the host side.
Furthermore, since this is for ROCm and not for graphics, I am less concerned
about supporting systems that require swappable GPU VRAM.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
next prev parent reply other threads:[~2024-12-22 2:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 10:04 [RFC PATCH 1/3] virtio-gpu api: add blob userptr resource Honglei Huang
2024-12-20 10:04 ` [RFC PATCH 2/3] drm/virtgpu " Honglei Huang
2024-12-20 10:04 ` [RFC PATCH 3/3] drm/virtio: implement blob userptr resource object Honglei Huang
2024-12-20 15:35 ` Simona Vetter
2024-12-22 1:59 ` Demi Marie Obenour [this message]
2024-12-27 2:24 ` Huang, Honglei1
2025-01-08 17:05 ` Simona Vetter
2025-01-25 0:42 ` Demi Marie Obenour
2025-01-29 19:40 ` Demi Marie Obenour
2025-01-29 20:54 ` Demi Marie Obenour
2025-01-31 0:33 ` Demi Marie Obenour
2025-02-06 10:53 ` Huang, Honglei1
2025-02-06 18:21 ` Demi Marie Obenour
2025-02-07 11:07 ` Huang, Honglei1
2025-02-08 2:30 ` Demi Marie Obenour
2025-02-08 2:43 ` Demi Marie Obenour
[not found] ` <d259279c-9989-410f-907d-9bf0b318bc84@amd.com>
2025-02-08 19:47 ` Demi Marie Obenour
[not found] ` <40485636-7ea3-4e34-b4bb-1ccaaadd4e47@amd.com>
2025-01-20 9:54 ` Huang, Honglei1
2025-01-29 19:46 ` Demi Marie Obenour
2025-02-04 10:45 ` Simona Vetter
2025-02-06 11:05 ` Huang, Honglei1
2025-02-03 8:25 ` [RFC PATCH 1/3] virtio-gpu api: add blob userptr resource Akihiko Odaki
2025-02-06 10:40 ` Huang, Honglei1
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=2fb36b50-4de2-4060-a4b7-54d221db8647@gmail.com \
--to=demiobenour@gmail.com \
--cc=Lingshan.Zhu@amd.com \
--cc=airlied@redhat.com \
--cc=akihiko.odaki@daynix.com \
--cc=dmitry.osipenko@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=honglei1.huang@amd.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olvaffe@gmail.com \
--cc=ray.huang@amd.com \
--cc=virtualization@lists.linux-foundation.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;
as well as URLs for NNTP newsgroup(s).