This is an experimental UAPI, without which it would be impossible
to virtualize Vulkan on Android using virtgpu.
This matches virtio-spec and latest upstream proposals:
https://markmail.org/message/akx5yzrubjcuteflhttps://gitlab.freedesktop.org/virgl/drm-misc-next/-/tree/resource-blob
crosvm has been updated to reflect the latest proposals. Once the
aosp crosvm is updated, Vulkan will break on Cuttlefish. As such, we
must update crosvm and the respective kernels at the same time.
First step: update the kernels, as this change does. This is not
a new feature, just maintainence and convergence on an existing
one.
Bug: 153580313
TEST=compile
Change-Id: I3305503264eb6859ace32376fdc91b2ee7cc10e7
Signed-off-by: Gurchetan Singh <gurchetansingh@google.com>
So ToT + v4.14 can share same hypercall interface.
TEST=compile
Signed-off-by: Gurchetan Singh <gurchetansingh@google.com>
Signed-off-by: Lingfeng Yang <lfy@google.com>
Bug: 153580313
Change-Id: Ifd6d8d50983461380f24988cef5a0435a2ecc59b
* Adds RESOURCE_MAP/RESOURCE_UNMAP
* Removes guest_memory_type/guest_caching_type in favor of a bitmask
* Removes EXECBUFFER_v2 until Q3
* Renames HOST_COHERENT to HOST_VISIBLE
BUG=chromium:924405
TEST=compile
Test:
- dEQP-VK.smoke* pass w/ gfxstream and host coherent memory enabled
- launch_cvd with 2d, virgl, and gfxstream modes work with current
- launch_cvd with 2d, virgl, and gfxstream modes work w/ crosvm modified
for host coherent memory
(https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2035595)
Signed-off-by: Lingfeng Yang <lfy@google.com>
Bug: 153580313
Change-Id: I04052c3d164c77c713bbc7251c357fd43653fa50
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens <stevensd@chromium.org>
(am from https://patchwork.kernel.org/patch/11431391/)
Fixes:
- Renumber out-of-tree virtio_gpu resource v2 feature bits. Although
that is technically a breaking change with respect to crosvm, all
usage of the bits is currently hidden behind flags which aren't
enabled outside of local builds.
BUG=b:136269340
TEST=boot ARCVM and launch play store
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2090952
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Bug: 153580313
Signed-off-by: Lingfeng Yang <lfy@google.com>
Change-Id: Ie48129c56b521ded1d33c4b4d3ea6ae05104447d
Upstream is foolishly using values for VIRTIO_GPU_RESP_OK_* that we are
already using in crosvm's virtio-gpu impl. In order to work around this,
this change renumbers to values that are unlikely to collide with
existing ones, and renaming the existing ones as *_LEGACY so that the
kernel may be compatible with both old and new versions of crosvm.
BUG=chromium:1047867
TEST=glxgears on crostini
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2051223
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Bug: 153580313
Signed-off-by: Lingfeng Yang <lfy@google.com>
Change-Id: I40d37c877d13392cc26274561f13684aabc54a23
Introduce the concept of memory types and memory regions to virtio-gpu.
Initially only memory regions composed of guest pages are supported
(VIRTIO_GPU_MEMORY_TRANSFER, pretty much like current backing storage
for resources). I expect support for other memory types will be added
later on.
VIRTIO_GPU_CMD_MEMORY_CREATE:
creates a new memory region.
VIRTIO_GPU_CMD_MEMORY_UNREF:
destroys a memory region.
VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 :
new command to create resources. It will (a) allow to specify the
memory type, (b) adds support planar resources and (c) returns
alignment, stride and size of the resource planes. The later
will be needed in case we support mapping host resources into the
guest some day.
VIRTIO_GPU_CMD_RESOURCE_ATTACH_MEMORY:
Use memory region as backing storage for the given resource.
The existing VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING command
can be used to detach.
Motivation: This separates storage management from resource management.
It allows memory pooling (vulkan support will most likely need this).
It makes things a bit more flexible in general, for example we can
represent gem objects as memory regions even if we don't know the format
yet (happens on dma-buf import for example).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 8eefa19d3e2ace7047c0082bf601c6f4f36f37fd)
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
BUG=chromium:924405
TEST=compile
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1591998
Reviewed-by: Robert Tarasov <tutankhamen@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
[rebase54(groeck): Context conflicts
Note that this patch does not match the patch with the same subject
on the kernel mailing list (https://patchwork.kernel.org/patch/10893777/).
No idea if that means that this version is more recent or older or
inofficial, or that it was modified locally.
]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Bug: 153580313
Signed-off-by: Lingfeng Yang <lfy@google.com>
Change-Id: I258a3a735678ddefd75b968d3f6874f394ac3e46
The feature allows the guest request an EDID blob (describing monitor
capabilities) for a given scanout (aka virtual monitor connector).
It brings a new command message, which has just a scanout field (beside
the standard virtio-gpu header) and a response message which carries the
EDID data.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181030063206.19528-2-kraxel@redhat.com
(cherry picked from commit 610c0c2b2813c36dc16838bbdbba4c29f8680dde)
Signed-off-by: Greg Hartman <ghartman@google.com>
BUG: 139386237
Change-Id: I1d4c11844307845b5829f1220b35938823ac7924
Kernel headers exported to userspace are should these types.
Fixes userspace compilation error:
error: unknown type name ‘uint8_t’
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
This patch adds a kms driver for the virtio gpu. The xorg modesetting
driver can handle the device just fine, the framebuffer for fbcon is
there too.
Qemu patches for the host side are under review currently.
The pci version of the device comes in two variants: with and without
vga compatibility. The former has a extra memory bar for the vga
framebuffer, the later is a pure virtio device. The only concern for
this driver is that in the virtio-vga case we have to kick out the
firmware framebuffer.
Initial revision has only 2d support, 3d (virgl) support requires
some more work on the qemu side and will be added later.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
