The flexible_array_impl! macro should not rely on the caller to import
FlexibleArray; use $crate::FlexibleArray to refer to it instead.
BUG=None
TEST=tools/presubmit
Change-Id: I9743a4cbc01deb6cdfadd98e63f4803a5572421c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3687064
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
In addition to SharedMemory, we allow File (e.g. mmap'd file) to be an
backing object of MemoryRegion.
BUG=b:194137301
TEST=kokoro
Change-Id: I9dafd028eaf74cf34820ba3f16e458c08ec67cb8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3159883
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
- Removes duplicated code
- Assumes "u32" as the type of the flexible array
length field, which should be fine.
BUG=b:173630595
TEST=compile and run
Change-Id: Ia2d9f74b823e06d2f2f0b60cebb8a3b999a9cba0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2848283
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
This patch adds support for creating udmabufs via a guest provided
sg-list. Ideally, we'd create the udmabuf from a virtio-gpu guest
dedicated heap, but that needs further investigation.
In terms of the protocol, these following prototype items are added:
BLOB_CREATE_GUEST_HANDLE: "create an udmabuf" or an OS-specific
equivalent. This can be used with the guest dedicated heap or system
memory. Right now, only system memory is used.
We also want to associate the udmabuf with any host side metadata. For
example, SET_SCANOUT_BLOB doesn't passthrough the modifiers since
virtio-gpu KMS + modifiers is annoying. Simple solution: just ask the
host for the modifier. This could also enable different caching types
if the guest blob is mappable (for example, the MSM GPU driver currently
only supports WC mappings. We might also want cached mappings for
camera).
Incidentals:
* Add a placeholder for RESOURCE_SYNC
BUG=chromium:892806, b:173630595
TEST=create a bunch of udmabufs from the guest
Change-Id: I4686d9f48938f10e7c265750a931d7d2d2d9611b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786291
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Allowing each region to have a separate backing FD will make it possible
to build GuestMemory from the vhost `SET_MEM_TABLE` message that
transmits the memory regions for virtio queues in vhost-user devices.
Change-Id: I6f9bc6136915da9d873ea896823e3b8f426ca69d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2795282
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Hello everyone ..! After 2.5 years of "on the side" inquiries,
I have finally completed my investigations [1] of the udmabuf!!
udmabuf is a kernel driver that turns memfd pages into dmabufs.
The original hope was it would reduce texture upload costs for
virgl, which it did for larger textures [2]. But no measurable
improvements where seen with real games. In addition, a more
advanced "gfx-streaming" model has since come into the horizon[3][4],
which is more performant, conformant, secure and simpler than
virgl. As such, building more on virgl does not seem to be best
option, but that's another story for another day.
Where does that leave udmabuf, then?!? The investigation was
able to turn up two possible use cases:
1) Intel integrated + dGPU PCI-passthrough resource sharing
When the dGPU is passthroughed into the guest, the dGPU's memory
is not available to the host. Ideally, for zero-copy, we would
like to get the render target out of the guest somehow and then
send to the display. Many approaches have been proposed, such
as Vivek Kasireddy's Vdmabuf driver [5]. The current thinking
is virtgpu guest blobs can be exported, and then imported into
the dGPU -- Vivek is looking into this approach right now ..!!
Sommelier or virtgpu KMS can then share the guest blob with the
host. It's a quite complex use case and requires changes to guest
Mesa GBM to get (such as metadata query) to get the right modifier.
Indeed, some would even say you need a virtgpu context type optimized
for sharing across domain boundaries. minigbm already supports this
for Android upstream's Virtual Graphics Interface (VGI) initiative.
2) Guest VRAM dedicated heap created udmabufs
This use case, proposed by automative virtualization expert Dmitry
Sepp [6], is primarily for automotive hypervisors (such COQOS).
It's typically not easy for such hypervisors to get zero-copy via
BLOB_MEM_HOST3D, and these hypervisors have had their homebrew
versions of udmabuf for many years. It's important to upstream the
workarounds that are currently done for such hypervisors. To increase
security and isolation, a guest dedicated heap is preferred over guest
system memory. We might even need dedicated queues, who knows.
crosvm seems like the most likely upstream target due to it's world
class blob support and open-source nature. As such, this CL adds basic
udmabuf capabilites so these use cases can be developed further via
crosvm.
[1] https://www.youtube.com/watch?v=lp6z3s1Gig0
[2] crrev.com/c/1325515
[3] goto.google.com/address-space-graphics
[4] https://drive.google.com/file/d/19K_6M8QUeOn-x7HVYvoNfnuC6G5vkR8f/view
[5] https://lists.freedesktop.org/archives/dri-devel/2021-February/296177.html
[6] https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/159
BUG=chromium:892806, b:173630595
TEST=Create a bunch of udmabufs from the guest, with the subsequent
patches
Change-Id: Ia8083c0aa065f303f660ec6875ff5fb76f5d7b4f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786290
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
