From: geoff@hostfission.com
To: qemu-devel@nongnu.org
Subject: Adding a memory alias breaks v-rings
Date: Thu, 24 Oct 2019 19:27:30 +1100 [thread overview]
Message-ID: <19efadd24a38e4e877459404ff12ac20@hostfission.com> (raw)
Hi All,
I have been working on adding a feature as a proof of concept to improve
the performance of applications like Looking Glass by avoiding
additional memory copies. My goal is to alias part of the IVSHMEM shared
memory over a pointer provided by the guest OS capture API (DXGI Desktop
Duplication or NVIDIA Frame Buffer Capture). I have managed to get this
working by adding a few additional configuration registers to the
IVSHMEM device and enhanced the IVSHMEM windows driver with suitable
IOCTLs to set this all up. While this concept is backwards it needs to
work this way as we do not have control over the destination buffer
allocation by the GPU driver.
This all works, however, it has exposed a bug (or I am doing things
improperly) with the way that vhost tracks memory. When calling
memory_region_add_subregion_overlap the memory listener in vhost fires
triggering vhost_region_add_section. According to the comments this code
depends on being called in memory address order, but because I am adding
the alias region late, it's out of order, and also splits the upper
memory region. This has the effect of corrupting/breaking one or more
random vrings, as evidenced by the crash/hang of vhost-net or other
virtio devices. The following and errors are also logged regarding
section alignment:
qemu-system-x86_64: vhost_region_add_section:Section rounded to
3c0000000 prior to previous 3fc4f9000
qemu-system-x86_64: vhost_region_add_section:Section rounded to
3c0000000 prior to previous 3fc4f9000
Here is the flat view after the alias has been added.
0000000100000000-00000003fc4f8fff (prio 0, ram): mem @0000000080000000
kvm
00000003fc4f9000-00000003fc4f9fff (prio 1, ram): ivshmem kvm
00000003fc4fa000-000000043fffffff (prio 0, ram): mem @000000037c4fa000
kvm
When the guest doesn't crash out due to the obvious corruption it is
possible to verify that the alias is in the right place and fully
functional. Unfortunately, I simply do not have enough of a grasp on
vhost to understand exactly what is going on and how to correct it.
Getting this feature working is highly desirable as it should be
possible to obtain GPU -> GPU memory transfers between guests without
requiring workstation/professional graphics cards.
Kind Regards,
Geoffrey McRae
next reply other threads:[~2019-10-24 8:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 8:27 geoff [this message]
2019-10-24 11:07 ` Adding a memory alias breaks v-rings Philippe Mathieu-Daudé
2019-10-24 11:28 ` geoff--- via
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=19efadd24a38e4e877459404ff12ac20@hostfission.com \
--to=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.