From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>,
Demi Marie Obenour <demi@invisiblethingslab.com>
Cc: "Xenia Ragiadakou" <burzalodowa@gmail.com>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
"Ray Huang" <ray.huang@amd.com>,
"Xen developer discussion" <xen-devel@lists.xenproject.org>,
"Andrew Cooper" <andrew.cooper3@citrix.com>
Subject: Re: Design session notes: GPU acceleration in Xen
Date: Fri, 14 Jun 2024 09:21:56 +0200 [thread overview]
Message-ID: <ZmvvlF0gpqFB7UC9@macbook> (raw)
In-Reply-To: <440d6444-3b02-4756-a4fa-02aae3b24b14@suse.com>
On Fri, Jun 14, 2024 at 08:38:51AM +0200, Jan Beulich wrote:
> On 13.06.2024 20:43, Demi Marie Obenour wrote:
> > GPU acceleration requires that pageable host memory be able to be mapped
> > into a guest.
>
> I'm sure it was explained in the session, which sadly I couldn't attend.
> I've been asking Ray and Xenia the same before, but I'm afraid it still
> hasn't become clear to me why this is a _requirement_. After all that's
> against what we're doing elsewhere (i.e. so far it has always been
> guest memory that's mapped in the host). I can appreciate that it might
> be more difficult to implement, but avoiding to violate this fundamental
> (kind of) rule might be worth the price (and would avoid other
> complexities, of which there may be lurking more than what you enumerate
> below).
My limited understanding (please someone correct me if wrong) is that
the GPU buffer (or context I think it's also called?) is always
allocated from dom0 (the owner of the GPU). The underling memory
addresses of such buffer needs to be mapped into the guest. The
buffer backing memory might be GPU MMIO from the device BAR(s) or
system RAM, and such buffer can be paged by the dom0 kernel at any
time (iow: changing the backing memory from MMIO to RAM or vice
versa). Also, the buffer must be contiguous in physical address
space.
I'm not sure it's possible to ensure that when using system RAM such
memory comes from the guest rather than the host, as it would likely
require some very intrusive hooks into the kernel logic, and
negotiation with the guest to allocate the requested amount of
memory and hand it over to dom0. If the maximum size of the buffer is
known in advance maybe dom0 can negotiate with the guest to allocate
such a region and grant it access to dom0 at driver attachment time.
One aspect that I'm lacking clarity is better understanding of how the
process of allocating and assigning a GPU buffer to a guest is
performed (I think this is the key to how GPU VirtIO native contexts
work?).
Another question I have, are guest expected to have a single GPU
buffer, or they can have multiple GPU buffers simultaneously
allocated?
Regards, Roger.
next prev parent reply other threads:[~2024-06-14 7:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-13 18:43 Design session notes: GPU acceleration in Xen Demi Marie Obenour
2024-06-14 6:38 ` Jan Beulich
2024-06-14 7:21 ` Roger Pau Monné [this message]
2024-06-14 8:12 ` Jan Beulich
2024-06-14 8:39 ` Roger Pau Monné
2024-06-17 0:38 ` Demi Marie Obenour
2024-06-17 7:46 ` Roger Pau Monné
2024-06-17 15:07 ` Demi Marie Obenour
2024-06-17 20:46 ` Marek Marczykowski-Górecki
2024-06-18 0:57 ` Demi Marie Obenour
2024-06-18 6:33 ` Christian König
2024-06-18 14:12 ` Demi Marie Obenour
2024-06-19 7:31 ` Christian König
2024-06-19 16:56 ` Alex Deucher
2024-06-18 14:43 ` Roger Pau Monné
2024-06-18 14:56 ` Demi Marie Obenour
2024-06-17 9:13 ` Jan Beulich
2024-06-14 16:44 ` Demi Marie Obenour
2024-06-17 9:07 ` Jan Beulich
2024-06-17 15:17 ` Demi Marie Obenour
2024-06-17 15:39 ` Jan Beulich
2024-06-17 16:02 ` Demi Marie Obenour
2024-06-14 17:55 ` Demi Marie Obenour
2024-06-14 16:35 ` Demi Marie Obenour
2024-06-17 9:05 ` Jan Beulich
2024-06-14 20:56 ` Demi Marie Obenour
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=ZmvvlF0gpqFB7UC9@macbook \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=burzalodowa@gmail.com \
--cc=demi@invisiblethingslab.com \
--cc=jbeulich@suse.com \
--cc=marmarek@invisiblethingslab.com \
--cc=ray.huang@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.