Sync upstream changes - #8
Open
github-actions[bot] wants to merge 68 commits into
Open
Conversation
Fixes the following error: `ERROR: Object <[DependencyHolder] holds [PkgConfigDependency]: <PkgConfigDependency vulkan: True []>> of type PkgConfigDependency does not support the `+` operator.` Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1620>
The same issue happened in Mesa https://gitlab.freedesktop.org/mesa/mesa/-/commit/4ae192a3d9f7861f40fc90ff4ebb4bf4112a9c80 part of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40862 Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1612>
v2: remove debug leftovers (tintou) Closes: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/656 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1622>
Since the check against the 32 used mask results in undefined behaviour the check does not protect against values that are larger than 31, the maxium allowed number of images and SSBOs. So check th eupper bound too. Closes: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/658 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1622>
Closes: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/657 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1622>
Motivation is for platforms such as iOS whose strict sanndbox does not allow for fork() or process spawning. New option "render-server-mode" enables 'thread' which will spawn the render server as a thread. The other option "render-server-worker" is still used to specify how the context communicates with the render server. When the rendering server is "thread" then the worker MUST ALSO be "thread". Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1626>
This change: - amend missing global optind reset for getopt_long - close client connection first to unblock server teardown - update config.h.meson for the new def - hide process-isolated server behind defs to suppress compiler warnings Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1626>
v2 (zzyiwei): drop render_log_init changes Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1626>
Callers of `virgl_logv` always use a '\n' at the end but callers of `virgl_prefixed_logv` does not. The default log handler will not print a new line so this makes the two logv implementations consistent. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1626>
Closes: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/666 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1632>
Do not ignore pixel read failure. Signed-off-by: Corentin Noël <corentin.noel@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1633>
In case of a ReadBuffer failure, this ensure that we won't return garbage memory to the client. Signed-off-by: Corentin Noël <corentin.noel@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1633>
vkr_metal_get_device() exports the underlying MTLDevice via vkExportMetalObjectsEXT() with a VkExportMetalDeviceInfoEXT. Per VK_EXT_metal_objects, the export intent must be declared at instance creation, otherwise the export is a spec violation (VUID-VkExportMetalObjectsInfoEXT-pNext-06791), flagged by the validation layer (MoltenVK happens to tolerate it). Chain a VkExportMetalObjectCreateInfoEXT with exportObjectType VK_EXPORT_METAL_OBJECT_TYPE_METAL_DEVICE_BIT_EXT into the VkInstanceCreateInfo pNext on macOS. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1635>
macOS shm_open() rejects O_CLOEXEC with EINVAL -- it only accepts O_RDONLY, O_RDWR, O_CREAT, O_EXCL and O_TRUNC. As a result os_create_anonymous_file() always failed on macOS and returned -1, breaking any caller that relies on it (e.g. the proxy render-server context shmem: proxy_context_init_shmem -> alloc_memfd), which surfaced as "failed to pre-initialize context" and RESOURCE_CREATE_BLOB failures. Drop O_CLOEXEC from the shm_open() flags and set close-on-exec explicitly with fcntl(F_SETFD, FD_CLOEXEC) after a successful open. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1634>
Fixes: fe078e3 ("drm: Add DRM context helpers") Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1636>
The shared memory is guest-writeable, so the guest always has control over its contents. Trusting the guest to select the number of bytes to unmap is a bad idea. For instance, if contiguous bytes after the mapping happen to be mapped, they could be unmapped as well. A subsequent mmap() could then reuse the same address space before other code dereferences the memory, resulting in use after free. Found by Claude Opus 4.8. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1637>
If a command handler fails while still leaving a response buffer set, drm_context_submit_cmd_dispatch() will leave the response buffer associated with the struct drm_context. If a subsequent call doesn't allocate a new response buffer, and succeeds, the response will be copied into the stale response buffer. However, the copy is made using _this_ command's hdr_off, without any new bounds check. This gives the guest a very powerful nonlinear out-of-bounds write primitive: it can a guest-controlled amount of data with guest-controlled contents at guest-controlled offset. This is almost certainly enough to get code execution. Fix this by freeing the response buffer before returning from drm_context_submit_cmd_dispatch(). A new response buffer will only be allocated after drm_context_rsp() has checked hdr->rsp_off to be in bounds. This is too subtle and subsequent bounds checks will be added later. Found by Claude Opus 4.8. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1637>
Relying on drm_context_rsp() to validate rsp->hdr_off is too fragile. It's too easy to have a mismatch between the buffer length and the validated offset, as the previous commit showed. Repeat the bounds check before performing the copy. This has an assert(false) if it fails, as the bounds check should have been done earlier. Discovered by Claude Opus 4.8. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1637>
… conditions match for imported resources" Fixes: 3716881 ("vrend: Ensure sampler view and framebuffer attachment swizzle conditions match for imported resources") Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1652>
The guest could cause an unbounded buffer allocation. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1643>
Avoid NULL deref. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1643>
The amdgpu renderer may not allocate all AMDGPU_HW_IP_NUM rings. If it allocates fewer, a too-large ring ID will access outside the bounds of the ctx->timelines array. This results in an information leak or, if the last_fence_fd field of the out of bounds drm_timeline struct is 0 or more, memory corruption. Found by Claude Opus 4.8. I looked at the fix it provided and wrote my own. Fixes: d27e04e ("drm: add amdgpu native-context implementation") Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1639>
If virgl_egl_image_from_bo fails, gbm_bo is set to NULL while storage_bits has VREND_STORAGE_GBM_BUFFER. When this resource is imported to venus, NULL is passed to gbm_bo_get_handle and host crashes. Signed-off-by: Toshinari Morikawa <morikawa.toshinari@jp.panasonic.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1644>
An IO variable may technically fit into thenumber of available variable slots, array actually require more than one IO slot, so check the range against the maximum number of supported IO slots. Closes: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/659 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1623>
There was no check that the number of request IDs provided by the guest fit in the guest-provided request buffer. Add the missing check. Found by Claude Opus 4.8. I adapted its fix. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1641>
If the guest tries to submit more than 128 IDs at once, fail the request. This avoids stack overflow, which is undefined behavior in C. Found by Claude Opus 4.8. I lightly modified the fix. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1641>
The same issue happened in Mesa https://gitlab.freedesktop.org/mesa/mesa/-/commit/dcfc90a8fc0d59309e8c37926b9a2c6334356271 part of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41871 Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1628>
Signed-off-by: Valentine Burley <valentine.burley@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1628>
Add the P210 format definition to virgl_formats enum. This format is used for 10-bit YUV 4:2:2 video decoding. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1659>
Replicate mesa side to add: - meson_subprojects for venus-protocol - --force-fallback-for - tiny helpers like comma_separated and no_werror Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1662>
Enable tiled GBM allocation by utilizing Vulkan for modifier selection and dmabuf allocation. This enables importing tiled GL framebuffers into venus on guest for better performance and stabilizes GBM allocation feature, making it available by default. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1654>
Below are added: - VK_KHR_shader_constant_data - VK_KHR_unified_image_layouts - VK_EXT_primitive_restart_index - VK_EXT_rgba10x6_formats - VK_EXT_shader_split_barrier - VK_EXT_shader_tile_image - VK_EXT_vertex_attribute_robustness - VK_EXT_zero_initialize_device_memory Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1663>
..so that we don't need to manually doing meson subporjects update. Fixes: c10b06d ("subprojects: uprev venus-protocol") Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1666>
Those are intended since we bind external memory to non-external image and buffer, and the external memory can be imported from gbm or udmabuf allocs or exportable from vulkan. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1667>
Change from int to int32_t in the protocol structs so we have a constant number of bits across all architectures. Add an explicit pad to `panfrost_ccmd_wait_bo_req`. Signed-off-by: Igor Torrente <igor.torrente@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1669>
… display In multi-gpu setups virglrenderer picks first available GPU for rendering operations. This not guaranteed to work when EGL display uses other GPU, dmabuf importing may be not possible or perform poorly. Make vrend and nctx to pick same GPU that used by EGL display. Reviewed-by: Yiwei Zhang <zzyiwei@google.com> Reviewed-by:Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1640>
Those jobs had a forced kernel version to use instead of Mesa's default. For virgl-traces, it is 9 months old, and venus-lavapipe is even older with 11 months. Also, the reason to fix the kernel version for venus-lavapipe seems long ago surpassed. Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1658>
The venus-lavapipe job is the one that currently uses the most time of the pipeline execution. But by sharding it, we can move it to the order of the others and also allow us to reduce the test per group size. Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1658>
Signed-off-by: Igor Torrente <igor.torrente@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1674>
Guest Android build of ANV driver exposes fake compute queue that uses same gfx engine as graphics queue, while using own fence context. This doesn't work properly with virtio native context because it didn't take into account that i915 may make use of sub-contexts. To fix this problem native context protocol gets extension that partitions virtio-gpu rings up to 8 engines per device context. Android VK CTS multi-queue tests are passing now. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1664>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated sync from upstream repository