All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: geoff@hostfission.com
Cc: qemu-devel@nongnu.org
Subject: Re: RFC: New device for zero-copy VM memory access
Date: Mon, 4 Nov 2019 11:26:56 +0100	[thread overview]
Message-ID: <20191104102656.caomxar3xbv2wd5n@sirius.home.kraxel.org> (raw)
In-Reply-To: <c83fe0e7157562c3c17598917977eb4d@hostfission.com>

  Hi,

> This new device, currently named `introspection` (which needs a more
> suitable name, porthole perhaps?), provides a means of translating
> guest physical addresses to host virtual addresses, and finally to the
> host offsets in RAM for file-backed memory guests. It does this by
> means of a simple protocol over a unix socket (chardev) which is
> supplied the appropriate fd for the VM's system RAM. The guest (in
> this case, Windows), when presented with the address of a userspace
> buffer and size, will mlock the appropriate pages into RAM and pass
> guest physical addresses to the virtual device.

So, if I understand things correctly, the workflow looks like this:

  (1) guest allocates buffers, using guest ram.
  (2) guest uses these buffers as render target for the gpu (pci-assigned I guess?).
  (3) guest passes guest physical address to qemu (via porthole device).
  (4) qemu translates gpa into file offset and passes offsets to
      the client application.
  (5) client application maps all guest ram, then uses the offsets from
      qemu to find the buffers.  Then goes displaying these buffers I guess.

Correct?

Performance aside for now, is it an option for your use case to simply
use both an emulated display device and the assigned gpu, then configure
screen mirroring inside the guest to get the guest display scanned out
to the host?

cheers,
  Gerd



  parent reply	other threads:[~2019-11-04 10:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29 14:31 RFC: New device for zero-copy VM memory access geoff
2019-10-29 22:53 ` geoff
2019-10-30  8:10   ` geoff
2019-10-30 18:52 ` Dr. David Alan Gilbert
2019-10-31  2:55   ` geoff
2019-10-31 11:52     ` geoff
2019-10-31 12:36     ` Peter Maydell
2019-10-31 13:24     ` Dr. David Alan Gilbert
2019-10-31 14:18       ` geoff
2019-10-31 14:52         ` Peter Maydell
2019-10-31 15:21           ` geoff
2019-10-31 15:52             ` Dr. David Alan Gilbert
2019-11-03 10:10               ` geoff
2019-11-03 11:03                 ` geoff
2019-11-04 11:55                   ` Dr. David Alan Gilbert
2019-11-04 12:05                     ` geoff
2019-11-04 16:35                       ` Dr. David Alan Gilbert
2019-11-05 10:05                       ` Marc-André Lureau
2019-11-26 18:25                         ` Dr. David Alan Gilbert
2019-11-04 10:26 ` Gerd Hoffmann [this message]
2019-11-04 10:31   ` geoff
2019-11-05  9:38     ` Gerd Hoffmann

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=20191104102656.caomxar3xbv2wd5n@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=geoff@hostfission.com \
    --cc=qemu-devel@nongnu.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.