[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [QEMU PATCH v4 09/13] virtio-gpu: Handle resource blob commands
- To: Huang Rui <ray.huang@xxxxxxx>
- From: Akihiko Odaki <akihiko.odaki@xxxxxxxxxx>
- Date: Wed, 6 Sep 2023 23:16:33 +0900
- Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx>, "Michael S . Tsirkin" <mst@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Antonio Caggiano <antonio.caggiano@xxxxxxxxxxxxx>, "Dr . David Alan Gilbert" <dgilbert@xxxxxxxxxx>, Robert Beckett <bob.beckett@xxxxxxxxxxxxx>, Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx>, Alex Bennée <alex.bennee@xxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Gurchetan Singh <gurchetansingh@xxxxxxxxxxxx>, "ernunes@xxxxxxxxxx" <ernunes@xxxxxxxxxx>, Philippe Mathieu-Daudé <philmd@xxxxxxxxxx>, Alyssa Ross <hi@xxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "Deucher, Alexander" <Alexander.Deucher@xxxxxxx>, "Koenig, Christian" <Christian.Koenig@xxxxxxx>, "Ragiadakou, Xenia" <Xenia.Ragiadakou@xxxxxxx>, "Pelloux-Prayer, Pierre-Eric" <Pierre-eric.Pelloux-prayer@xxxxxxx>, "Huang, Honglei1" <Honglei1.Huang@xxxxxxx>, "Zhang, Julia" <Julia.Zhang@xxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
- Delivery-date: Wed, 06 Sep 2023 14:16:54 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 2023/09/06 16:56, Huang Rui wrote:
On Wed, Sep 06, 2023 at 11:39:09AM +0800, Akihiko Odaki wrote:
On 2023/09/06 12:09, Huang Rui wrote:
On Tue, Sep 05, 2023 at 05:20:43PM +0800, Akihiko Odaki wrote:
On 2023/09/05 18:08, Huang Rui wrote:
On Thu, Aug 31, 2023 at 06:24:32PM +0800, Akihiko Odaki wrote:
On 2023/08/31 18:32, Huang Rui wrote:
From: Antonio Caggiano <antonio.caggiano@xxxxxxxxxxxxx>
Support BLOB resources creation, mapping and unmapping by calling the
new stable virglrenderer 0.10 interface. Only enabled when available and
via the blob config. E.g. -device virtio-vga-gl,blob=true
Signed-off-by: Antonio Caggiano <antonio.caggiano@xxxxxxxxxxxxx>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx>
Signed-off-by: Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>
Signed-off-by: Huang Rui <ray.huang@xxxxxxx>
---
v1->v2:
- Remove unused #include "hw/virtio/virtio-iommu.h"
- Add a local function, called virgl_resource_destroy(), that is used
to release a vgpu resource on error paths and in resource_unref.
- Remove virtio_gpu_virgl_resource_unmap from
virtio_gpu_cleanup_mapping(),
since this function won't be called on blob resources and also because
blob resources are unmapped via virgl_cmd_resource_unmap_blob().
- In virgl_cmd_resource_create_blob(), do proper cleanup in error paths
and move QTAILQ_INSERT_HEAD(&g->reslist, res, next) after the resource
has been fully initialized.
- Memory region has a different life-cycle from virtio gpu resources
i.e. cannot be released synchronously along with the vgpu resource.
So, here the field "region" was changed to a pointer that will be
released automatically once the memory region is unparented and all
of its references have been released.
Also, since the pointer can be used to indicate whether the blob
is mapped, the explicit field "mapped" was removed.
- In virgl_cmd_resource_map_blob(), add check on the value of
res->region, to prevent beeing called twice on the same resource.
- Remove direct references to parent_obj.
- Separate declarations from code.
hw/display/virtio-gpu-virgl.c | 213 +++++++++++++++++++++++++++++++++
hw/display/virtio-gpu.c | 4 +-
include/hw/virtio/virtio-gpu.h | 5 +
meson.build | 4 +
4 files changed, 225 insertions(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 312953ec16..17b634d4ee 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -17,6 +17,7 @@
#include "trace.h"
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-gpu.h"
+#include "hw/virtio/virtio-gpu-bswap.h"
#include "ui/egl-helpers.h"
@@ -78,9 +79,24 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
virgl_renderer_resource_create(&args, NULL, 0);
}
+static void virgl_resource_destroy(VirtIOGPU *g,
+ struct virtio_gpu_simple_resource *res)
+{
+ if (!res)
+ return;
+
+ QTAILQ_REMOVE(&g->reslist, res, next);
+
+ virtio_gpu_cleanup_mapping_iov(g, res->iov, res->iov_cnt);
+ g_free(res->addrs);
+
+ g_free(res);
+}
+
static void virgl_cmd_resource_unref(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
+ struct virtio_gpu_simple_resource *res;
struct virtio_gpu_resource_unref unref;
struct iovec *res_iovs = NULL;
int num_iovs = 0;
@@ -88,13 +104,22 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
VIRTIO_GPU_FILL_CMD(unref);
trace_virtio_gpu_cmd_res_unref(unref.resource_id);
+ res = virtio_gpu_find_resource(g, unref.resource_id);
+
virgl_renderer_resource_detach_iov(unref.resource_id,
&res_iovs,
&num_iovs);
if (res_iovs != NULL && num_iovs != 0) {
virtio_gpu_cleanup_mapping_iov(g, res_iovs, num_iovs);
+ if (res) {
+ res->iov = NULL;
+ res->iov_cnt = 0;
+ }
}
+
virgl_renderer_resource_unref(unref.resource_id);
+
+ virgl_resource_destroy(g, res);
}
static void virgl_cmd_context_create(VirtIOGPU *g,
@@ -426,6 +451,183 @@ static void virgl_cmd_get_capset(VirtIOGPU *g,
g_free(resp);
}
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+
+static void virgl_cmd_resource_create_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+ struct virtio_gpu_simple_resource *res;
+ struct virtio_gpu_resource_create_blob cblob;
+ struct virgl_renderer_resource_create_blob_args virgl_args = { 0 };
+ int ret;
+
+ VIRTIO_GPU_FILL_CMD(cblob);
+ virtio_gpu_create_blob_bswap(&cblob);
+ trace_virtio_gpu_cmd_res_create_blob(cblob.resource_id, cblob.size);
+
+ if (cblob.resource_id == 0) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource id 0 is not allowed\n",
+ __func__);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ res = virtio_gpu_find_resource(g, cblob.resource_id);
+ if (res) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already exists %d\n",
+ __func__, cblob.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ res = g_new0(struct virtio_gpu_simple_resource, 1);
+ if (!res) {
+ cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+ return;
+ }
+
+ res->resource_id = cblob.resource_id;
+ res->blob_size = cblob.size;
+
+ if (cblob.blob_mem != VIRTIO_GPU_BLOB_MEM_HOST3D) {
+ ret = virtio_gpu_create_mapping_iov(g, cblob.nr_entries, sizeof(cblob),
+ cmd, &res->addrs, &res->iov,
+ &res->iov_cnt);
+ if (!ret) {
+ g_free(res);
+ cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+ return;
+ }
+ }
+
+ QTAILQ_INSERT_HEAD(&g->reslist, res, next);
+
+ virgl_args.res_handle = cblob.resource_id;
+ virgl_args.ctx_id = cblob.hdr.ctx_id;
+ virgl_args.blob_mem = cblob.blob_mem;
+ virgl_args.blob_id = cblob.blob_id;
+ virgl_args.blob_flags = cblob.blob_flags;
+ virgl_args.size = cblob.size;
+ virgl_args.iovecs = res->iov;
+ virgl_args.num_iovs = res->iov_cnt;
+
+ ret = virgl_renderer_resource_create_blob(&virgl_args);
+ if (ret) {
+ virgl_resource_destroy(g, res);
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: virgl blob create error: %s\n",
+ __func__, strerror(-ret));
+ cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+ }
+}
+
+static void virgl_cmd_resource_map_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+ struct virtio_gpu_simple_resource *res;
+ struct virtio_gpu_resource_map_blob mblob;
+ int ret;
+ void *data;
+ uint64_t size;
+ struct virtio_gpu_resp_map_info resp;
+ VirtIOGPUBase *b = VIRTIO_GPU_BASE(g);
+
+ VIRTIO_GPU_FILL_CMD(mblob);
+ virtio_gpu_map_blob_bswap(&mblob);
+
+ if (mblob.resource_id == 0) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource id 0 is not allowed\n",
+ __func__);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ res = virtio_gpu_find_resource(g, mblob.resource_id);
+ if (!res) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource does not exist %d\n",
+ __func__, mblob.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+ if (res->region) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already mapped %d\n",
+ __func__, mblob.resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ ret = virgl_renderer_resource_map(res->resource_id, &data, &size);
+ if (ret) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: resource map error: %s\n",
+ __func__, strerror(-ret));
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+ return;
+ }
+
+ res->region = g_new0(MemoryRegion, 1);
+ if (!res->region) {
+ virgl_renderer_resource_unmap(res->resource_id);
+ cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+ return;
+ }
+ memory_region_init_ram_device_ptr(res->region, OBJECT(g), NULL, size,
data);
I think memory_region_init_ram_ptr() should be used instead.
Would you mind to explain the reason?
The documentation comment of memory_region_init_ram_device_ptr() says:
> A RAM device represents a mapping to a physical device, such as to a
> PCI MMIO BAR of an vfio-pci assigned device. The memory region may be
> mapped into the VM address space and access to the region will modify
> memory directly. However, the memory region should not be included in
> a memory dump (device may not be enabled/mapped at the time of the
> dump), and operations incompatible with manipulating MMIO should be
> avoided. Replaces skip_dump flag.
In my understanding it's not MMIO so memory_region_init_ram_ptr() should
be used instead.
It actually maybe the video memory (mmio) or system memory here. :-)
We will get the host memory for blob from host with
virgl_renderer_resource_map() in virglrenderer. In virglrenderer, there are two
types of VIRGL_RESOURCE_FD_DMABUF and VIRGL_RESOURCE_FD_SHM to indicate the
memory types. The shmem is the system memory that won't need GPU
accessible, and dmabuf is the memory that required GPU accessible. Host
kernel amdgpu driver will register dma-buf to export the resource buffer
for sharing, and here, it may have video memory that exposed by amdgpu pcie
bar0 in the dma-buf buffers. And we also have system memory(gtt) that can
be mapped as gpu page tables for gpu accessible.
07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Renoir (rev c1) (prog-if 00 [VGA controller])
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Renoir
Flags: bus master, fast devsel, latency 0, IRQ 56
Memory at fcc0000000 (64-bit, prefetchable) [size=256M]
Memory at fcd0000000 (64-bit, prefetchable) [size=2M]
I/O ports at 1000 [size=256]
Memory at d0400000 (32-bit, non-prefetchable) [size=512K]
Capabilities: <access denied>
Kernel driver in use: amdgpu
Kernel modules: amdgpu
In my understanding it is not relevant if the memory is backed by device
or not. Here MMIO means memory-mapping I/O registers that has
side-effects during accesses. Reading such a register may acknowledge an
interrupt for example and the unit of writes may also matter.
memory_region_init_ram_device_ptr() ensures no supurious memory read
will not happen and word accesses are preserved.
They do not matter for video memory even if it lies in a separate device
memory. In this sense the name "memory_region_init_ram_device_ptr" is
somewhat misnomer.
OK. Thanks for the clarification.
After traced the code, if memory_region_init_ram_device_ptr(), it will use
memory_region_dispatch_write() to call into memory_region_ram_device_write()
which registered as ram_device_mem_ops to write ram_block->host with offset
dword by dword. And if we use memory_region_init_ram_ptr(), the
flatview_write_continue() will use memmove() to write buf into ramblock while
we write the blob memory. May I know whether you mean the "memmove" may have an
interrupt or supurious memory access?
memmove can split one word write into smaller writes and that is
implementation dependent.
git blame is your friend if you want to know more. Particularly commits
21e00fa55f ("memory: Replace skip_dump flag with "ram_device"") and
4a2e242bbb ("memory: Don't use memcpy for ram_device regions" [the
memmove call was used to be memcpy) may interest you.
Regards,
Akihiko Odaki
|
