All of lore.kernel.org
 help / color / mirror / Atom feed
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Cc: "Jan Beulich" <jbeulich@suse.com>,
	"Xenia Ragiadakou" <burzalodowa@gmail.com>,
	"Ray Huang" <ray.huang@amd.com>,
	"Xen developer discussion" <xen-devel@lists.xenproject.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Direct Rendering Infrastructure development"
	<dri-devel@lists.freedesktop.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Qubes OS Development Mailing List"
	<qubes-devel@googlegroups.com>
Subject: Re: Design session notes: GPU acceleration in Xen
Date: Mon, 17 Jun 2024 20:57:14 -0400	[thread overview]
Message-ID: <ZnDbaply6KaBUKJb@itl-email> (raw)
In-Reply-To: <ZnCglhYlXmRPBZXE@mail-itl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, Jun 17, 2024 at 10:46:13PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Jun 17, 2024 at 09:46:29AM +0200, Roger Pau Monné wrote:
> > On Sun, Jun 16, 2024 at 08:38:19PM -0400, Demi Marie Obenour wrote:
> > > In both cases, the device physical
> > > addresses are identical to dom0’s physical addresses.
> > 
> > Yes, but a PV dom0 physical address space can be very scattered.
> > 
> > IIRC there's an hypercall to request physically contiguous memory for
> > PV, but you don't want to be using that every time you allocate a
> > buffer (not sure it would support the sizes needed by the GPU
> > anyway).
> 
> Indeed that isn't going to fly. In older Qubes versions we had PV
> sys-net with PCI passthrough for a network card. After some uptime it
> was basically impossible to restart and still have enough contagious
> memory for a network driver, and there it was about _much_ smaller
> buffers, like 2M or 4M. At least not without shutting down a lot more
> things to free some more memory.

Ouch!  That makes me wonder if all GPU drivers actually need physically
contiguous buffers, or if it is (as I suspect) driver-specific.  CCing
Christian König who has mentioned issues in this area.

Given the recent progress on PVH dom0, is it reasonable to assume that
PVH dom0 will be ready in time for R4.3, and that therefore Qubes OS
doesn't need to worry about this problem on x86?
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmZw22kACgkQsoi1X/+c
IsGqtA/+INEbVP6pjKoMOJStaXajIvx19hJFU5HJQT0FBe4u2VXd3wfhK5gbJ90P
NrlE3Lstzper0qBG7Lt8lt4DAcL9Q3Ml9d8M0K7z6VYIKPqiu2Wh/P25HD7r+Adn
L2AMwnKUHtC02LJpT1Cjt/acKU3En9TMd35RhCNf4K+c9Swodtea3iOo7GzgQjNA
TFMAYiiIlhwQIvThrVlcKktCMZajvhudxwfZTd3EfUkIQbMtc/ydkeqL92nV9Fg4
uz+AEeDDNhCGsEjrFUFTXKnXc/28jpVIc4mXyGW+x4dginRjrjRVmtNrnz/1wO+S
X/xVUVnvLoTUXI+dKI9y5XmobVAJzLNZaEOEfnKePj5zA2ayRfnWybPBjzJuU+S4
wKevyBDlTuOdgtOT9nktd+qzXBQYtreEu8f+t9sEezURpVU/oOyrVn7Ui0RMtZID
W3sXJH3NfVb3mWCsYOMpJyzb5VYfYR5PWN6Ggln/CHvfLTDI8TKdaO41INkXLlTC
fA1cXVSKPn/VX9LRIFcQ81v9MGBAFkDX4Mf7z7xodi9Qopj+o2Yw66g5vLrPxPCH
asJSdnrnaZAtZSsbEhY4uV5+4QLD0dyNUqj+HxRlODFwhpDyervCikfp0MoSsWmT
qFvFHkiSqkx7E33QaVjmcGmFv4eWTVunYxW0j8tWnpWQLNLfPzY=
=H5gN
-----END PGP SIGNATURE-----


  reply	other threads:[~2024-06-18  0:57 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é
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 [this message]
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=ZnDbaply6KaBUKJb@itl-email \
    --to=demi@invisiblethingslab.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=burzalodowa@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jbeulich@suse.com \
    --cc=marmarek@invisiblethingslab.com \
    --cc=qubes-devel@googlegroups.com \
    --cc=ray.huang@amd.com \
    --cc=roger.pau@citrix.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.