Re: [PATCH v7 00/10] Support blob memory and venus on qemu
On Thu, Apr 11, 2024 at 06:19:52PM +0800, Dmitry Osipenko wrote: > Hello, > > This series enables Vulkan Venus context support on virtio-gpu. > Upstreaming of Venus to Qemu was originally started by Antonio Caggiano, > later Huang Rui continued the effort. I'm now taking it over because > Rui will be busy for awhile and he asked me to do so. > Thanks Dmitry! :-) Please go ahead and it's important implementation which is not only on venus but also on virtio native context. Best Regards, Ray
Re: [PATCH v6 10/11] virtio-gpu: Initialize Venus
On Tue, Jan 02, 2024 at 09:33:11PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Tue, Dec 19, 2023 at 11:55 AM Huang Rui wrote:
> >
> > From: Antonio Caggiano
> >
> > Request Venus when initializing VirGL.
> >
> > Signed-off-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > Changes in v6:
> > - Remove the unstable API flags check because virglrenderer is already 1.0.
> > - Squash the render server flag support into "Initialize Venus".
> >
> > hw/display/virtio-gpu-virgl.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index f35a751824..c523a6717a 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -964,6 +964,10 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> > }
> > #endif
> >
> > +#ifdef VIRGL_RENDERER_VENUS
> > +flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER;
> > +#endif
> > +
>
> I wonder if it's a good idea to initialize venus by default. It
> doesn't seem to require vulkan during initialization, but this may
> evolve. Make it optional?
>
I am fine. In fact, vulkan is widely used for graphic area such as gaming,
compute, VR/AR, etc.
Thanks,
Ray
> > ret = virgl_renderer_init(g, flags, _gpu_3d_cbs);
> > if (ret != 0) {
> > error_report("virgl could not be initialized: %d", ret);
> > --
> > 2.25.1
> >
>
>
> --
> Marc-André Lureau
Re: [PATCH v6 08/11] virtio-gpu: Resource UUID
On Tue, Jan 02, 2024 at 08:49:54PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Tue, Dec 19, 2023 at 11:55 AM Huang Rui wrote:
> >
> > From: Antonio Caggiano
> >
> > Enable resource UUID feature and implement command resource assign UUID.
> > This is done by introducing a hash table to map resource IDs to their
> > UUIDs.
>
> I agree with Akihiko, what about putting QemuUUID in struct
> virtio_gpu_simple_resource?
OK, I will add a member of UUID in simple resource structure.
>
> (I also doubt about the hash table usefulness, but I don't know
> how/why the UUID is used)
>
The system cannot be without this patch, let me figure it out the reason.
Thanks,
Ray
> >
> > Signed-off-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > Changes in v6:
> > - Set resource uuid as option.
> > - Implement optional subsection of vmstate_virtio_gpu_resource_uuid_state
> > or virtio live migration.
> > - Use g_int_hash/g_int_equal instead of the default.
> > - Move virtio_vgpu_simple_resource initialization in the earlier new patch
> > "virtio-gpu: Introduce virgl_gpu_resource structure"
> >
> > hw/display/trace-events| 1 +
> > hw/display/virtio-gpu-base.c | 4 ++
> > hw/display/virtio-gpu-virgl.c | 3 +
> > hw/display/virtio-gpu.c| 119 +
> > include/hw/virtio/virtio-gpu.h | 7 ++
> > 5 files changed, 134 insertions(+)
> >
> > diff --git a/hw/display/trace-events b/hw/display/trace-events
> > index 2336a0ca15..54d6894c59 100644
> > --- a/hw/display/trace-events
> > +++ b/hw/display/trace-events
> > @@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t
> > size) "res 0x%x, size %" P
> > virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
> > +virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
> > diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
> > index 37af256219..6bcee3882f 100644
> > --- a/hw/display/virtio-gpu-base.c
> > +++ b/hw/display/virtio-gpu-base.c
> > @@ -236,6 +236,10 @@ virtio_gpu_base_get_features(VirtIODevice *vdev,
> > uint64_t features,
> > features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
> > }
> >
> > +if (virtio_gpu_resource_uuid_enabled(g->conf)) {
> > +features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
> > +}
> > +
> > return features;
> > }
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 5a3a292f79..be9da6e780 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -777,6 +777,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
> > /* TODO add security */
> > virgl_cmd_ctx_detach_resource(g, cmd);
> > break;
> > +case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
> > +virtio_gpu_resource_assign_uuid(g, cmd);
> > +break;
> > case VIRTIO_GPU_CMD_GET_CAPSET_INFO:
> > virgl_cmd_get_capset_info(g, cmd);
> > break;
> > diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> > index 8189c392dc..466debb256 100644
> > --- a/hw/display/virtio-gpu.c
> > +++ b/hw/display/virtio-gpu.c
> > @@ -958,6 +958,37 @@ virtio_gpu_resource_detach_backing(VirtIOGPU *g,
> > virtio_gpu_cleanup_mapping(g, res);
> > }
> >
> > +void virtio_gpu_resource_assign_uuid(VirtIOGPU *g,
> > + struct virtio_gpu_ctrl_command *cmd)
> > +{
> > +struct virtio_gpu_simple_resource *res;
> > +struct virtio_gpu_resource_assign_uuid assign;
> > +struct virtio_gpu_resp_resource_uuid resp;
> > +QemuUUID *uuid;
> > +
> > +VIRTIO_GPU_FILL_CMD(assign);
> > +virtio_gpu_bswap_32(, sizeof(assign));
> > +trace_virtio_gpu_cmd_res_assign_uuid(assign.resource_id);
> > +
> > +res = virtio_gpu_find_check_resource(g, assign.resource_id, false,
> > __func__, >error);
> > +if (!res) {
> > +return;
> > +}
> > +
> > +memset(, 0
Re: [PATCH v6 07/11] virtio-gpu: Handle resource blob commands
On Wed, Jan 10, 2024 at 04:51:31PM +0800, Pierre-Eric Pelloux-Prayer wrote:
>
>
> Le 09/01/2024 à 17:50, Pierre-Eric Pelloux-Prayer a écrit :
> >
> >
> > Le 19/12/2023 à 08:53, Huang Rui a écrit :
> >> From: Antonio Caggiano
> >>
> >> 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
> >> Signed-off-by: Dmitry Osipenko
> >> Signed-off-by: Xenia Ragiadakou
> >> Signed-off-by: Huang Rui
> >> ---
> >>
> >> Changes in v6:
> >> - Use new struct virgl_gpu_resource.
> >> - Unmap, unref and destroy the resource only after the memory region
> >> has been completely removed.
> >> - In unref check whether the resource is still mapped.
> >> - In unmap_blob check whether the resource has been already unmapped.
> >> - Fix coding style
> >>
> >> hw/display/virtio-gpu-virgl.c | 274 +-
> >> hw/display/virtio-gpu.c | 4 +-
> >> meson.build | 4 +
> >> 3 files changed, 276 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> >> index faab374336..5a3a292f79 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"
> >> @@ -24,8 +25,62 @@
> >> struct virgl_gpu_resource {
> >> struct virtio_gpu_simple_resource res;
> >> + uint32_t ref;
> >> + VirtIOGPU *g;
> >> +
> >> +#ifdef HAVE_VIRGL_RESOURCE_BLOB
> >> + /* only blob resource needs this region to be mapped as guest mmio */
> >> + MemoryRegion *region;
> >> +#endif
> >> };
> >> +static void vres_get_ref(struct virgl_gpu_resource *vres)
> >> +{
> >> + uint32_t ref;
> >> +
> >> + ref = qatomic_fetch_inc(>ref);
> >> + g_assert(ref < INT_MAX);
> >> +}
> >> +
> >> +static void virgl_resource_destroy(struct virgl_gpu_resource *vres)
> >> +{
> >> + struct virtio_gpu_simple_resource *res;
> >> + VirtIOGPU *g;
> >> +
> >> + if (!vres) {
> >> + return;
> >> + }
> >> +
> >> + g = vres->g;
> >> + res = >res;
> >> + QTAILQ_REMOVE(>reslist, res, next);
> >> + virtio_gpu_cleanup_mapping(g, res);
> >> + g_free(vres);
> >> +}
> >> +
> >> +static void virgl_resource_unref(struct virgl_gpu_resource *vres)
> >> +{
> >> + struct virtio_gpu_simple_resource *res;
> >> +
> >> + if (!vres) {
> >> + return;
> >> + }
> >> +
> >> + res = >res;
> >> + virgl_renderer_resource_detach_iov(res->resource_id, NULL, NULL);
> >> + virgl_renderer_resource_unref(res->resource_id);
> >> +}
> >> +
> >> +static void vres_put_ref(struct virgl_gpu_resource *vres)
> >> +{
> >> + g_assert(vres->ref > 0);
> >> +
> >> + if (qatomic_fetch_dec(>ref) == 1) {
> >> + virgl_resource_unref(vres);
> >> + virgl_resource_destroy(vres);
> >> + }
> >> +}
> >> +
> >> static struct virgl_gpu_resource *
> >> virgl_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id)
> >> {
> >> @@ -59,6 +114,8 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
> >> c2d.width, c2d.height);
> >> vres = g_new0(struct virgl_gpu_resource, 1);
> >> + vres_get_ref(vres);
> >> + vres->g = g;
> >> vres->res.width = c2d.width;
> >> vres->res.height = c2d.height;
> >> vres->res.format = c2d.format;
> >> @@ -91,6 +148,8 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> >> c3d.width, c3d.height, c3d.depth);
> >> vres = g_new0(struct virgl_gpu_resour
Re: [PATCH v6 05/11] virtio-gpu: Introduce virgl_gpu_resource structure
On Tue, Jan 02, 2024 at 07:52:04PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Tue, Dec 19, 2023 at 11:55 AM Huang Rui wrote:
> >
> > Introduce a new virgl_gpu_resource data structure and helper functions
> > for virgl. It's used to add new member which is specific for virgl in
> > following patches of blob memory support.
> >
> > Signed-off-by: Huang Rui
> > ---
> >
> > New patch:
> > - Introduce new struct virgl_gpu_resource to store virgl specific members.
> > - Move resource initialization from path "virtio-gpu: Resource UUID" here.
> > - Remove error handling of g_new0, because glib will abort() on OOM.
> > - Set iov and iov_cnt in struct virtio_gpu_simple_resource for all types
> > of resources.
> >
> > hw/display/virtio-gpu-virgl.c | 84 ++-
> > 1 file changed, 64 insertions(+), 20 deletions(-)
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 5bbc8071b2..faab374336 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -22,6 +22,23 @@
> >
> > #include
> >
> > +struct virgl_gpu_resource {
> > +struct virtio_gpu_simple_resource res;
> > +};
> > +
> > +static struct virgl_gpu_resource *
> > +virgl_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id)
> > +{
> > +struct virtio_gpu_simple_resource *res;
> > +
> > +res = virtio_gpu_find_resource(g, resource_id);
> > +if (!res) {
> > +return NULL;
> > +}
> > +
> > +return container_of(res, struct virgl_gpu_resource, res);
> > +}
> > +
> > #if VIRGL_RENDERER_CALLBACKS_VERSION >= 4
> > static void *
> > virgl_get_egl_display(G_GNUC_UNUSED void *cookie)
> > @@ -35,11 +52,19 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
> > {
> > struct virtio_gpu_resource_create_2d c2d;
> > struct virgl_renderer_resource_create_args args;
> > +struct virgl_gpu_resource *vres;
> >
> > VIRTIO_GPU_FILL_CMD(c2d);
> > trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
> > c2d.width, c2d.height);
> >
>
> It should check the resource doesn't already exist (similar to 2d code)
>
Will add the resource check here in V7.
Thanks,
Ray
> > +vres = g_new0(struct virgl_gpu_resource, 1);
> > +vres->res.width = c2d.width;
> > +vres->res.height = c2d.height;
> > +vres->res.format = c2d.format;
> > +vres->res.resource_id = c2d.resource_id;
> > +QTAILQ_INSERT_HEAD(>reslist, >res, next);
> > +
> > args.handle = c2d.resource_id;
> > args.target = 2;
> > args.format = c2d.format;
> > @@ -59,11 +84,19 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> > {
> > struct virtio_gpu_resource_create_3d c3d;
> > struct virgl_renderer_resource_create_args args;
> > +struct virgl_gpu_resource *vres;
> >
> > VIRTIO_GPU_FILL_CMD(c3d);
> > trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
> > c3d.width, c3d.height, c3d.depth);
> >
>
> same
>
> > +vres = g_new0(struct virgl_gpu_resource, 1);
> > +vres->res.width = c3d.width;
> > +vres->res.height = c3d.height;
> > +vres->res.format = c3d.format;
> > +vres->res.resource_id = c3d.resource_id;
> > +QTAILQ_INSERT_HEAD(>reslist, >res, next);
> > +
> > args.handle = c3d.resource_id;
> > args.target = c3d.target;
> > args.format = c3d.format;
> > @@ -82,19 +115,23 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
> > struct virtio_gpu_ctrl_command *cmd)
> > {
> > struct virtio_gpu_resource_unref unref;
> > -struct iovec *res_iovs = NULL;
> > -int num_iovs = 0;
> > +struct virgl_gpu_resource *vres;
> >
> > VIRTIO_GPU_FILL_CMD(unref);
> > trace_virtio_gpu_cmd_res_unref(unref.resource_id);
> >
> > -virgl_renderer_resource_detach_iov(unref.resource_id,
> > - _iovs,
> > - _iovs);
> > -if (res_iovs != NULL && num_iovs != 0) {
> > -virtio_gpu_cleanup_mapping_iov(g, res_iovs, num_iovs);
> > +vres = virgl_gpu_find_resource(g, unref.resource_id);
> > +if (!vres) {
> > +cmd->error = VIR
Re: [PATCH v6 05/11] virtio-gpu: Introduce virgl_gpu_resource structure
On Thu, Dec 21, 2023 at 01:43:37PM +0800, Akihiko Odaki wrote: > On 2023/12/19 22:27, Huang Rui wrote: > > On Tue, Dec 19, 2023 at 08:35:27PM +0800, Akihiko Odaki wrote: > >> On 2023/12/19 16:53, Huang Rui wrote: > >>> Introduce a new virgl_gpu_resource data structure and helper functions > >>> for virgl. It's used to add new member which is specific for virgl in > >>> following patches of blob memory support. > >> > >> The name is ambigious. It should tell that it's specific for virgl. > > > > How about "virgl_resource" which inherits virtio_gpu_simple_resource? But > > this name is exactly same with the name in virglrenderer. > > You can prefix it with virtio_gpu_virgl as virtio_gpu_virgl_init() and > other functions do. > Thanks, will update it in V7. Ray
Re: [PATCH v6 03/11] virtio-gpu: Support context init feature with virglrenderer
On Tue, Jan 02, 2024 at 07:43:20PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Tue, Dec 19, 2023 at 11:54 AM Huang Rui wrote:
> >
> > Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
> > feature flags.
> > We would like to enable the feature with virglrenderer, so add to create
> > virgl renderer context with flags using context_id when valid.
> >
> > Originally-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > Changes in v6:
> > - Handle the case while context_init is disabled.
> > - Enable context_init by default.
> >
> > hw/display/virtio-gpu-virgl.c | 13 +++--
> > hw/display/virtio-gpu.c | 4
> > 2 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 8bb7a2c21f..5bbc8071b2 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
> > trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
> > cc.debug_name);
> >
> > -virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
> > - cc.debug_name);
> > +#ifdef HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS
> > +if (cc.context_init &&
> > virtio_gpu_context_init_enabled(g->parent_obj.conf)) {
> > +virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
> > + cc.context_init,
> > + cc.nlen,
> > + cc.debug_name);
> > +return;
> > +}
> > +#endif
> > +
> > +virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
> > }
> >
> > static void virgl_cmd_context_destroy(VirtIOGPU *g,
> > diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> > index b016d3bac8..8b2f4c6be3 100644
> > --- a/hw/display/virtio-gpu.c
> > +++ b/hw/display/virtio-gpu.c
> > @@ -1619,6 +1619,10 @@ static Property virtio_gpu_properties[] = {
> > DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
> > VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
> > DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
> > +#ifdef HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS
> > +DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
> > +VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, true),
> > +#endif
>
> Does it make sense to make this configurable? If the context to be
> created asked for a capset id but the one created doesn't respect it,
> what's the outcome?
>
> It looks like it should instead set cmd->error.
>
Hmm, how about setting VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED in
virtio_gpu_gl_device_realize(). And then drop context_init DEFINE_PROP_BIT
in virtio_gpu_properties. We treat all gl device as context_init enabled
and let virglrenderer report the error if command fails.
Thanks,
Ray
Re: [PATCH v6 01/11] linux-headers: Update to kernel headers to add venus capset
On Tue, Jan 02, 2024 at 06:42:44PM +0800, Marc-André Lureau wrote: > Hi > > On Thu, Dec 21, 2023 at 10:55 AM Akihiko Odaki > wrote: > > > > On 2023/12/19 23:14, Peter Maydell wrote: > > > On Tue, 19 Dec 2023 at 13:49, Huang Rui wrote: > > >> > > >> On Tue, Dec 19, 2023 at 08:20:22PM +0800, Akihiko Odaki wrote: > > >>> On 2023/12/19 16:53, Huang Rui wrote: > > >>>> Sync up kernel headers to update venus macro till they are merged into > > >>>> mainline. > > >>> > > >>> Thanks for sorting things out with the kernel and spec. > > >>> > > >>>> > > >>>> Signed-off-by: Huang Rui > > >>>> --- > > >>>> > > >>>> Changes in v6: > > >>>> - Venus capset is applied in kernel, so update it in qemu for future > > >>>> use. > > >>>> > > >>>> https://lore.kernel.org/lkml/b79dcf75-c9e8-490e-644f-3b97d95f7...@collabora.com/ > > >>>> https://cgit.freedesktop.org/drm-misc/commit/?id=216d86b9a430f3280e5b631c51e6fd1a7774cfa0 > > >>> Please include the link to the upstream commit in the commit message. > > >> > > >> So far, it's in drm maintainers' branch not in kernel mainline yet. Do I > > >> need to wait it to be merged into kernel mainline? > > > > > > For an RFC patchset, no. For patches to be merged into QEMU > > > the headers change must be in the kernel mainline, and the > > > QEMU commit that updates our copy of the headers must be a > > > full-sync done with scripts/update-linux-headers.sh, not a > > > manual edit. > > > > Apparently the kernel change is unlikely to be merged to mainline before > > QEMU 9.0 so we need to come up with some idea to deal with this. May I know when QEMU 9.0 will be released? > > > > The release of Linux 6.7 is near and the development of 6.8 will start > > soon. So it was nice if the change made into 6.8, but unfortunately it > > missed the *probably last* drm-misc tree pull request for 6.8: > > https://lore.kernel.org/all/aqpn5miejmkks7pbcfex7b6u63uwsruywxsnr3x5ljs45qatin@nbkkej2elk46/ > > > > It will still get into linux-next so we may retrieve headers from > > linux-next. Or we may add the definition to > > hw/display/virtio-gpu-virgl.c; the duplicate definition warning will > > tell when the definition becomes no longer necessary. I'm fine with > > either option. > > The second option seems better to me, as it can avoid pulling unwanted > changes. > I will keep an eye on dri-devel mailing list. And ok, I will add the definition in virtio-gpu-virgl.c and remove it once kernel patch is merged by mainline. Thanks, Ray
Re: [PATCH v6 01/11] linux-headers: Update to kernel headers to add venus capset
On Tue, Dec 19, 2023 at 08:20:22PM +0800, Akihiko Odaki wrote: > On 2023/12/19 16:53, Huang Rui wrote: > > Sync up kernel headers to update venus macro till they are merged into > > mainline. > > Thanks for sorting things out with the kernel and spec. > > > > > Signed-off-by: Huang Rui > > --- > > > > Changes in v6: > > - Venus capset is applied in kernel, so update it in qemu for future use. > > > > https://lore.kernel.org/lkml/b79dcf75-c9e8-490e-644f-3b97d95f7...@collabora.com/ > > https://cgit.freedesktop.org/drm-misc/commit/?id=216d86b9a430f3280e5b631c51e6fd1a7774cfa0 > Please include the link to the upstream commit in the commit message. OK, I will add this info in qemu commit message. Thanks, Ray
Re: [PATCH v6 01/11] linux-headers: Update to kernel headers to add venus capset
On Tue, Dec 19, 2023 at 10:14:28PM +0800, Peter Maydell wrote: > On Tue, 19 Dec 2023 at 13:49, Huang Rui wrote: > > > > On Tue, Dec 19, 2023 at 08:20:22PM +0800, Akihiko Odaki wrote: > > > On 2023/12/19 16:53, Huang Rui wrote: > > > > Sync up kernel headers to update venus macro till they are merged into > > > > mainline. > > > > > > Thanks for sorting things out with the kernel and spec. > > > > > > > > > > > Signed-off-by: Huang Rui > > > > --- > > > > > > > > Changes in v6: > > > > - Venus capset is applied in kernel, so update it in qemu for future > > > > use. > > > > > > > > https://lore.kernel.org/lkml/b79dcf75-c9e8-490e-644f-3b97d95f7...@collabora.com/ > > > > https://cgit.freedesktop.org/drm-misc/commit/?id=216d86b9a430f3280e5b631c51e6fd1a7774cfa0 > > > Please include the link to the upstream commit in the commit message. > > > > So far, it's in drm maintainers' branch not in kernel mainline yet. Do I > > need to wait it to be merged into kernel mainline? > > For an RFC patchset, no. For patches to be merged into QEMU > the headers change must be in the kernel mainline, and the > QEMU commit that updates our copy of the headers must be a > full-sync done with scripts/update-linux-headers.sh, not a > manual edit. > Yes, according to the comment in previous series, I am using update-linux-headers.sh to generate the patch. But here, the patch is not merged in mainline yet. Thanks, Ray
Re: [PATCH v6 01/11] linux-headers: Update to kernel headers to add venus capset
On Tue, Dec 19, 2023 at 08:20:22PM +0800, Akihiko Odaki wrote: > On 2023/12/19 16:53, Huang Rui wrote: > > Sync up kernel headers to update venus macro till they are merged into > > mainline. > > Thanks for sorting things out with the kernel and spec. > > > > > Signed-off-by: Huang Rui > > --- > > > > Changes in v6: > > - Venus capset is applied in kernel, so update it in qemu for future use. > > > > https://lore.kernel.org/lkml/b79dcf75-c9e8-490e-644f-3b97d95f7...@collabora.com/ > > https://cgit.freedesktop.org/drm-misc/commit/?id=216d86b9a430f3280e5b631c51e6fd1a7774cfa0 > Please include the link to the upstream commit in the commit message. So far, it's in drm maintainers' branch not in kernel mainline yet. Do I need to wait it to be merged into kernel mainline? Thanks, Ray
Re: [PATCH v6 05/11] virtio-gpu: Introduce virgl_gpu_resource structure
On Tue, Dec 19, 2023 at 08:35:27PM +0800, Akihiko Odaki wrote: > On 2023/12/19 16:53, Huang Rui wrote: > > Introduce a new virgl_gpu_resource data structure and helper functions > > for virgl. It's used to add new member which is specific for virgl in > > following patches of blob memory support. > > The name is ambigious. It should tell that it's specific for virgl. How about "virgl_resource" which inherits virtio_gpu_simple_resource? But this name is exactly same with the name in virglrenderer. Thanks, Ray
Re: [PATCH v6 02/11] virtio-gpu: Configure new feature flag context_create_with_flags for virglrenderer
On Tue, Dec 19, 2023 at 05:09:27PM +0800, Antonio Caggiano wrote:
> Hi Huang Rui,
>
> Thank you for this new version.
>
> All patches which I did not sign off are reviewed by me :)
Thanks Antonio! May I have your RB in next version?
Best Regards,
Ray
>
> Cheers,
> Antonio Caggiano
>
> On 19/12/2023 08:53, Huang Rui wrote:
> > Configure a new feature flag (context_create_with_flags) for
> > virglrenderer.
> >
> > Originally-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > Changes in v6:
> > - Move macros configurations under virgl.found() and rename
> >HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS.
> >
> > meson.build | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/meson.build b/meson.build
> > index ec01f8b138..ea52ef1b9c 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1050,6 +1050,10 @@ if not get_option('virglrenderer').auto() or
> > have_system or have_vhost_user_gpu
> >cc.has_member('struct
> > virgl_renderer_resource_info_ext', 'd3d_tex2d',
> > prefix: '#include
> > ',
> > dependencies: virgl))
> > +config_host_data.set('HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS',
> > +
> > cc.has_function('virgl_renderer_context_create_with_flags',
> > + prefix: '#include
> > ',
> > + dependencies: virgl))
> > endif
> > endif
> > rutabaga = not_found
[PATCH v6 00/11] Support blob memory and venus on qemu
f/xen_summit_2023_virtgpu_demo.mp4 QEMU repository: - https://gitlab.freedesktop.org/rui/qemu-xen/-/commits/upstream-for-virtio-gpu Thanks, Ray Antonio Caggiano (4): virtio-gpu: Handle resource blob commands virtio-gpu: Resource UUID virtio-gpu: Support Venus capset virtio-gpu: Initialize Venus Dmitry Osipenko (1): virtio-gpu: Don't require udmabuf when blobs and virgl are enabled Huang Rui (4): linux-headers: Update to kernel headers to add venus capset virtio-gpu: Configure new feature flag context_create_with_flags for virglrenderer virtio-gpu: Support context init feature with virglrenderer virtio-gpu: Introduce virgl_gpu_resource structure Robert Beckett (1): virtio-gpu: make blob scanout use dmabuf fd Xenia Ragiadakou (1): softmmu/memory: enable automatic deallocation of memory regions hw/display/trace-events | 1 + hw/display/virtio-gpu-base.c| 4 + hw/display/virtio-gpu-virgl.c | 495 ++-- hw/display/virtio-gpu.c | 132 +- include/hw/virtio/virtio-gpu.h | 13 + include/standard-headers/linux/virtio_gpu.h | 2 + meson.build | 8 + system/memory.c | 2 + 8 files changed, 627 insertions(+), 30 deletions(-) -- 2.25.1
[PATCH v6 11/11] virtio-gpu: make blob scanout use dmabuf fd
From: Robert Beckett
This relies on a virglrenderer change to include the dmabuf fd when
returning resource info.
Signed-off-by: Robert Beckett
Signed-off-by: Huang Rui
---
Changes in v6:
- Add scanout_blob function for virtio-gpu-virgl.
- Update for new virgl_gpu_resource.
hw/display/virtio-gpu-virgl.c | 104 +
hw/display/virtio-gpu.c| 4 +-
include/hw/virtio/virtio-gpu.h | 6 ++
3 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index c523a6717a..c384225a98 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -18,6 +18,7 @@
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-gpu.h"
#include "hw/virtio/virtio-gpu-bswap.h"
+#include "hw/virtio/virtio-gpu-pixman.h"
#include "ui/egl-helpers.h"
@@ -726,6 +727,106 @@ static void virgl_cmd_resource_unmap_blob(VirtIOGPU *g,
object_unparent(OBJECT(mr));
}
+static void virgl_cmd_set_scanout_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virgl_gpu_resource *vres;
+struct virtio_gpu_framebuffer fb = { 0 };
+struct virtio_gpu_set_scanout_blob ss;
+struct virgl_renderer_resource_info info;
+uint64_t fbend;
+
+VIRTIO_GPU_FILL_CMD(ss);
+virtio_gpu_scanout_blob_bswap();
+trace_virtio_gpu_cmd_set_scanout_blob(ss.scanout_id, ss.resource_id,
+ ss.r.width, ss.r.height, ss.r.x,
+ ss.r.y);
+
+if (ss.scanout_id >= g->parent_obj.conf.max_outputs) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: illegal scanout id specified %d",
+ __func__, ss.scanout_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_SCANOUT_ID;
+return;
+}
+
+if (ss.resource_id == 0) {
+virtio_gpu_disable_scanout(g, ss.scanout_id);
+return;
+}
+
+if (ss.width < 16 ||
+ss.height < 16 ||
+ss.r.x + ss.r.width > ss.width ||
+ss.r.y + ss.r.height > ss.height) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: illegal scanout %d bounds for"
+ " resource %d, rect (%d,%d)+%d,%d, fb %d %d\n",
+ __func__, ss.scanout_id, ss.resource_id,
+ ss.r.x, ss.r.y, ss.r.width, ss.r.height,
+ ss.width, ss.height);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+return;
+}
+
+if (!console_has_gl(g->parent_obj.scanout[ss.scanout_id].con)) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: unable to scanout blot without
GL!\n", __func__);
+return;
+}
+
+vres = virgl_gpu_find_resource(g, ss.resource_id);
+if (!vres) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: illegal resource specified %d\n",
+ __func__, ss.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+if (virgl_renderer_resource_get_info(ss.resource_id, )) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: illegal virgl resource specified %d\n",
+ __func__, ss.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+if (!vres->res.dmabuf_fd && info.fd)
+vres->res.dmabuf_fd = info.fd;
+
+fb.format = virtio_gpu_get_pixman_format(ss.format);
+if (!fb.format) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: host couldn't handle guest format %d\n",
+ __func__, ss.format);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+return;
+}
+
+fb.bytes_pp = DIV_ROUND_UP(PIXMAN_FORMAT_BPP(fb.format), 8);
+fb.width = ss.width;
+fb.height = ss.height;
+fb.stride = ss.strides[0];
+fb.offset = ss.offsets[0] + ss.r.x * fb.bytes_pp + ss.r.y * fb.stride;
+
+fbend = fb.offset;
+fbend += fb.stride * (ss.r.height - 1);
+fbend += fb.bytes_pp * ss.r.width;
+if (fbend > vres->res.blob_size) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: fb end out of range\n",
+ __func__);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+return;
+}
+
+g->parent_obj.enable = 1;
+if (virtio_gpu_update_dmabuf(g, ss.scanout_id, >res,
+ , )) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: failed to update dmabuf\n", __func__);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+return;
+}
+virtio_gpu_update_scanout(g, ss.scanout_id, >res, );
+}
+
#endif /* HAVE_VIRGL_RESOURCE_BLOB */
void virtio_g
[PATCH v6 10/11] virtio-gpu: Initialize Venus
From: Antonio Caggiano
Request Venus when initializing VirGL.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
Changes in v6:
- Remove the unstable API flags check because virglrenderer is already 1.0.
- Squash the render server flag support into "Initialize Venus".
hw/display/virtio-gpu-virgl.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index f35a751824..c523a6717a 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -964,6 +964,10 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
}
#endif
+#ifdef VIRGL_RENDERER_VENUS
+flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER;
+#endif
+
ret = virgl_renderer_init(g, flags, _gpu_3d_cbs);
if (ret != 0) {
error_report("virgl could not be initialized: %d", ret);
--
2.25.1
[PATCH v6 08/11] virtio-gpu: Resource UUID
From: Antonio Caggiano
Enable resource UUID feature and implement command resource assign UUID.
This is done by introducing a hash table to map resource IDs to their
UUIDs.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
Changes in v6:
- Set resource uuid as option.
- Implement optional subsection of vmstate_virtio_gpu_resource_uuid_state
or virtio live migration.
- Use g_int_hash/g_int_equal instead of the default.
- Move virtio_vgpu_simple_resource initialization in the earlier new patch
"virtio-gpu: Introduce virgl_gpu_resource structure"
hw/display/trace-events| 1 +
hw/display/virtio-gpu-base.c | 4 ++
hw/display/virtio-gpu-virgl.c | 3 +
hw/display/virtio-gpu.c| 119 +
include/hw/virtio/virtio-gpu.h | 7 ++
5 files changed, 134 insertions(+)
diff --git a/hw/display/trace-events b/hw/display/trace-events
index 2336a0ca15..54d6894c59 100644
--- a/hw/display/trace-events
+++ b/hw/display/trace-events
@@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t size)
"res 0x%x, size %" P
virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
+virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index 37af256219..6bcee3882f 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -236,6 +236,10 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
}
+if (virtio_gpu_resource_uuid_enabled(g->conf)) {
+features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
+}
+
return features;
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 5a3a292f79..be9da6e780 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -777,6 +777,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
/* TODO add security */
virgl_cmd_ctx_detach_resource(g, cmd);
break;
+case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
+virtio_gpu_resource_assign_uuid(g, cmd);
+break;
case VIRTIO_GPU_CMD_GET_CAPSET_INFO:
virgl_cmd_get_capset_info(g, cmd);
break;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 8189c392dc..466debb256 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -958,6 +958,37 @@ virtio_gpu_resource_detach_backing(VirtIOGPU *g,
virtio_gpu_cleanup_mapping(g, res);
}
+void virtio_gpu_resource_assign_uuid(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_simple_resource *res;
+struct virtio_gpu_resource_assign_uuid assign;
+struct virtio_gpu_resp_resource_uuid resp;
+QemuUUID *uuid;
+
+VIRTIO_GPU_FILL_CMD(assign);
+virtio_gpu_bswap_32(, sizeof(assign));
+trace_virtio_gpu_cmd_res_assign_uuid(assign.resource_id);
+
+res = virtio_gpu_find_check_resource(g, assign.resource_id, false,
__func__, >error);
+if (!res) {
+return;
+}
+
+memset(, 0, sizeof(resp));
+resp.hdr.type = VIRTIO_GPU_RESP_OK_RESOURCE_UUID;
+
+uuid = g_hash_table_lookup(g->resource_uuids, _id);
+if (!uuid) {
+uuid = g_new(QemuUUID, 1);
+qemu_uuid_generate(uuid);
+g_hash_table_insert(g->resource_uuids, _id, uuid);
+}
+
+memcpy(resp.uuid, uuid, sizeof(QemuUUID));
+virtio_gpu_ctrl_response(g, cmd, , sizeof(resp));
+}
+
void virtio_gpu_simple_process_cmd(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
@@ -1006,6 +1037,9 @@ void virtio_gpu_simple_process_cmd(VirtIOGPU *g,
case VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING:
virtio_gpu_resource_detach_backing(g, cmd);
break;
+case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
+virtio_gpu_resource_assign_uuid(g, cmd);
+break;
default:
cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
break;
@@ -1400,6 +1434,57 @@ static int virtio_gpu_blob_load(QEMUFile *f, void
*opaque, size_t size,
return 0;
}
+static int virtio_gpu_resource_uuid_save(QEMUFile *f, void *opaque, size_t
size,
+ const VMStateField *field,
+ JSONWriter *vmdesc)
+{
+VirtIOGPU *g = opaque;
+struct virtio_gpu_simple_resource *res;
+QemuUUID *uuid;
+
+/* in 2d mode we should never find unprocessed commands here */
+assert(QTAILQ_EMPTY(>cmdq));
+
+QTAILQ_FOREACH(r
[PATCH v6 06/11] softmmu/memory: enable automatic deallocation of memory regions
From: Xenia Ragiadakou
When the memory region has a different life-cycle from that of her parent,
could be automatically released, once has been unparent and once all of her
references have gone away, via the object's free callback.
However, currently, the address space subsystem keeps references to the
memory region without first incrementing its object's reference count.
As a result, the automatic deallocation of the object, not taking into
account those references, results in use-after-free memory corruption.
More specifically, reference to the memory region is kept in flatview
ranges. If the reference count of the memory region is not incremented,
flatview_destroy(), that is asynchronous, may be called after memory
region's destruction. If the reference count of the memory region is
incremented, memory region's destruction will take place after
flatview_destroy() has released its references.
This patch increases the reference count of an owned memory region object
on each memory_region_ref() and decreases it on each memory_region_unref().
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
---
Changes in v6:
- remove in-code comment because it is confusing and explain the issue,
that the patch attempts to fix, with more details in commit message
system/memory.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/system/memory.c b/system/memory.c
index 304fa843ea..4d5e7e7a4c 100644
--- a/system/memory.c
+++ b/system/memory.c
@@ -1824,6 +1824,7 @@ void memory_region_ref(MemoryRegion *mr)
* we do not ref/unref them because it slows down DMA sensibly.
*/
if (mr && mr->owner) {
+object_ref(OBJECT(mr));
object_ref(mr->owner);
}
}
@@ -1832,6 +1833,7 @@ void memory_region_unref(MemoryRegion *mr)
{
if (mr && mr->owner) {
object_unref(mr->owner);
+object_unref(OBJECT(mr));
}
}
--
2.25.1
[PATCH v6 07/11] virtio-gpu: Handle resource blob commands
From: Antonio Caggiano
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
Signed-off-by: Dmitry Osipenko
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
---
Changes in v6:
- Use new struct virgl_gpu_resource.
- Unmap, unref and destroy the resource only after the memory region
has been completely removed.
- In unref check whether the resource is still mapped.
- In unmap_blob check whether the resource has been already unmapped.
- Fix coding style
hw/display/virtio-gpu-virgl.c | 274 +-
hw/display/virtio-gpu.c | 4 +-
meson.build | 4 +
3 files changed, 276 insertions(+), 6 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index faab374336..5a3a292f79 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"
@@ -24,8 +25,62 @@
struct virgl_gpu_resource {
struct virtio_gpu_simple_resource res;
+uint32_t ref;
+VirtIOGPU *g;
+
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+/* only blob resource needs this region to be mapped as guest mmio */
+MemoryRegion *region;
+#endif
};
+static void vres_get_ref(struct virgl_gpu_resource *vres)
+{
+uint32_t ref;
+
+ref = qatomic_fetch_inc(>ref);
+g_assert(ref < INT_MAX);
+}
+
+static void virgl_resource_destroy(struct virgl_gpu_resource *vres)
+{
+struct virtio_gpu_simple_resource *res;
+VirtIOGPU *g;
+
+if (!vres) {
+return;
+}
+
+g = vres->g;
+res = >res;
+QTAILQ_REMOVE(>reslist, res, next);
+virtio_gpu_cleanup_mapping(g, res);
+g_free(vres);
+}
+
+static void virgl_resource_unref(struct virgl_gpu_resource *vres)
+{
+struct virtio_gpu_simple_resource *res;
+
+if (!vres) {
+return;
+}
+
+res = >res;
+virgl_renderer_resource_detach_iov(res->resource_id, NULL, NULL);
+virgl_renderer_resource_unref(res->resource_id);
+}
+
+static void vres_put_ref(struct virgl_gpu_resource *vres)
+{
+g_assert(vres->ref > 0);
+
+if (qatomic_fetch_dec(>ref) == 1) {
+virgl_resource_unref(vres);
+virgl_resource_destroy(vres);
+}
+}
+
static struct virgl_gpu_resource *
virgl_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id)
{
@@ -59,6 +114,8 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
c2d.width, c2d.height);
vres = g_new0(struct virgl_gpu_resource, 1);
+vres_get_ref(vres);
+vres->g = g;
vres->res.width = c2d.width;
vres->res.height = c2d.height;
vres->res.format = c2d.format;
@@ -91,6 +148,8 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
c3d.width, c3d.height, c3d.depth);
vres = g_new0(struct virgl_gpu_resource, 1);
+vres_get_ref(vres);
+vres->g = g;
vres->res.width = c3d.width;
vres->res.height = c3d.height;
vres->res.format = c3d.format;
@@ -126,12 +185,21 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
return;
}
-virgl_renderer_resource_detach_iov(unref.resource_id, NULL, NULL);
-virgl_renderer_resource_unref(unref.resource_id);
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+if (vres->region) {
+VirtIOGPUBase *b = VIRTIO_GPU_BASE(g);
+MemoryRegion *mr = vres->region;
+
+warn_report("%s: blob resource %d not unmapped",
+__func__, unref.resource_id);
+vres->region = NULL;
+memory_region_set_enabled(mr, false);
+memory_region_del_subregion(>hostmem, mr);
+object_unparent(OBJECT(mr));
+}
+#endif /* HAVE_VIRGL_RESOURCE_BLOB */
-QTAILQ_REMOVE(>reslist, >res, next);
-virtio_gpu_cleanup_mapping(g, >res);
-g_free(vres);
+vres_put_ref(vres);
}
static void virgl_cmd_context_create(VirtIOGPU *g,
@@ -470,6 +538,191 @@ static void virgl_cmd_get_capset(VirtIOGPU *g,
g_free(resp);
}
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+
+static void virgl_resource_unmap(struct virgl_gpu_resource *vres)
+{
+if (!vres) {
+return;
+}
+
+virgl_renderer_resource_unmap(vres->res.resource_id);
+
+vres_put_ref(vres);
+}
+
+static void virgl_resource_blob_async_unmap(void *obj)
+{
+MemoryRegion *mr = MEMORY_REGION(obj);
+struct virgl_gpu_resource *vres = mr->opaque;
+
+virgl_resource_unmap(vres);
+
+g_free(obj);
+}
+
+static void virgl_cmd_resource_create_blob(VirtIOGPU *g,
+
[PATCH v6 09/11] virtio-gpu: Support Venus capset
From: Antonio Caggiano
Add support for the Venus capset, which enables Vulkan support through
the Venus Vulkan driver for virtio-gpu.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
No change in v6.
hw/display/virtio-gpu-virgl.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index be9da6e780..f35a751824 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -506,6 +506,11 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
virgl_renderer_get_cap_set(resp.capset_id,
_max_version,
_max_size);
+} else if (info.capset_index == 2) {
+resp.capset_id = VIRTIO_GPU_CAPSET_VENUS;
+virgl_renderer_get_cap_set(resp.capset_id,
+ _max_version,
+ _max_size);
} else {
resp.capset_max_version = 0;
resp.capset_max_size = 0;
@@ -978,10 +983,18 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
{
-uint32_t capset2_max_ver, capset2_max_size;
+uint32_t capset2_max_ver, capset2_max_size, num_capsets;
+num_capsets = 1;
+
virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
- _max_ver,
- _max_size);
+ _max_ver,
+ _max_size);
+num_capsets += capset2_max_ver ? 1 : 0;
+
+virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
+ _max_ver,
+ _max_size);
+num_capsets += capset2_max_size ? 1 : 0;
-return capset2_max_ver ? 2 : 1;
+return num_capsets;
}
--
2.25.1
[PATCH v6 04/11] virtio-gpu: Don't require udmabuf when blobs and virgl are enabled
From: Dmitry Osipenko
The udmabuf usage is mandatory when virgl is disabled and blobs feature
enabled in the Qemu machine configuration. If virgl and blobs are enabled,
then udmabuf requirement is optional. Since udmabuf isn't widely supported
by a popular Linux distros today, let's relax the udmabuf requirement for
blobs=on,virgl=on. Now, a full-featured virtio-gpu acceleration is
available to Qemu users without a need to have udmabuf available in the
system.
Reviewed-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
Signed-off-by: Huang Rui
---
No change in v6.
hw/display/virtio-gpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 8b2f4c6be3..4c3ec9d0ea 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1443,6 +1443,7 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error
**errp)
if (virtio_gpu_blob_enabled(g->parent_obj.conf)) {
if (!virtio_gpu_rutabaga_enabled(g->parent_obj.conf) &&
+!virtio_gpu_virgl_enabled(g->parent_obj.conf) &&
!virtio_gpu_have_udmabuf()) {
error_setg(errp, "need rutabaga or udmabuf for blob resources");
return;
--
2.25.1
[PATCH v6 05/11] virtio-gpu: Introduce virgl_gpu_resource structure
Introduce a new virgl_gpu_resource data structure and helper functions
for virgl. It's used to add new member which is specific for virgl in
following patches of blob memory support.
Signed-off-by: Huang Rui
---
New patch:
- Introduce new struct virgl_gpu_resource to store virgl specific members.
- Move resource initialization from path "virtio-gpu: Resource UUID" here.
- Remove error handling of g_new0, because glib will abort() on OOM.
- Set iov and iov_cnt in struct virtio_gpu_simple_resource for all types
of resources.
hw/display/virtio-gpu-virgl.c | 84 ++-
1 file changed, 64 insertions(+), 20 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 5bbc8071b2..faab374336 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -22,6 +22,23 @@
#include
+struct virgl_gpu_resource {
+struct virtio_gpu_simple_resource res;
+};
+
+static struct virgl_gpu_resource *
+virgl_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id)
+{
+struct virtio_gpu_simple_resource *res;
+
+res = virtio_gpu_find_resource(g, resource_id);
+if (!res) {
+return NULL;
+}
+
+return container_of(res, struct virgl_gpu_resource, res);
+}
+
#if VIRGL_RENDERER_CALLBACKS_VERSION >= 4
static void *
virgl_get_egl_display(G_GNUC_UNUSED void *cookie)
@@ -35,11 +52,19 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_2d c2d;
struct virgl_renderer_resource_create_args args;
+struct virgl_gpu_resource *vres;
VIRTIO_GPU_FILL_CMD(c2d);
trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
c2d.width, c2d.height);
+vres = g_new0(struct virgl_gpu_resource, 1);
+vres->res.width = c2d.width;
+vres->res.height = c2d.height;
+vres->res.format = c2d.format;
+vres->res.resource_id = c2d.resource_id;
+QTAILQ_INSERT_HEAD(>reslist, >res, next);
+
args.handle = c2d.resource_id;
args.target = 2;
args.format = c2d.format;
@@ -59,11 +84,19 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_3d c3d;
struct virgl_renderer_resource_create_args args;
+struct virgl_gpu_resource *vres;
VIRTIO_GPU_FILL_CMD(c3d);
trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
c3d.width, c3d.height, c3d.depth);
+vres = g_new0(struct virgl_gpu_resource, 1);
+vres->res.width = c3d.width;
+vres->res.height = c3d.height;
+vres->res.format = c3d.format;
+vres->res.resource_id = c3d.resource_id;
+QTAILQ_INSERT_HEAD(>reslist, >res, next);
+
args.handle = c3d.resource_id;
args.target = c3d.target;
args.format = c3d.format;
@@ -82,19 +115,23 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
struct virtio_gpu_resource_unref unref;
-struct iovec *res_iovs = NULL;
-int num_iovs = 0;
+struct virgl_gpu_resource *vres;
VIRTIO_GPU_FILL_CMD(unref);
trace_virtio_gpu_cmd_res_unref(unref.resource_id);
-virgl_renderer_resource_detach_iov(unref.resource_id,
- _iovs,
- _iovs);
-if (res_iovs != NULL && num_iovs != 0) {
-virtio_gpu_cleanup_mapping_iov(g, res_iovs, num_iovs);
+vres = virgl_gpu_find_resource(g, unref.resource_id);
+if (!vres) {
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
}
+
+virgl_renderer_resource_detach_iov(unref.resource_id, NULL, NULL);
virgl_renderer_resource_unref(unref.resource_id);
+
+QTAILQ_REMOVE(>reslist, >res, next);
+virtio_gpu_cleanup_mapping(g, >res);
+g_free(vres);
}
static void virgl_cmd_context_create(VirtIOGPU *g,
@@ -310,44 +347,51 @@ static void virgl_resource_attach_backing(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
struct virtio_gpu_resource_attach_backing att_rb;
-struct iovec *res_iovs;
-uint32_t res_niov;
+struct virgl_gpu_resource *vres;
int ret;
VIRTIO_GPU_FILL_CMD(att_rb);
trace_virtio_gpu_cmd_res_back_attach(att_rb.resource_id);
+vres = virgl_gpu_find_resource(g, att_rb.resource_id);
+if (!vres) {
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
ret = virtio_gpu_create_mapping_iov(g, att_rb.nr_entries, sizeof(att_rb),
-cmd, NULL, _iovs, _niov);
+cmd, NULL, >res.iov,
+>res.iov_cnt);
if (ret != 0) {
cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
[PATCH v6 03/11] virtio-gpu: Support context init feature with virglrenderer
Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
feature flags.
We would like to enable the feature with virglrenderer, so add to create
virgl renderer context with flags using context_id when valid.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
Changes in v6:
- Handle the case while context_init is disabled.
- Enable context_init by default.
hw/display/virtio-gpu-virgl.c | 13 +++--
hw/display/virtio-gpu.c | 4
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 8bb7a2c21f..5bbc8071b2 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
cc.debug_name);
-virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
- cc.debug_name);
+#ifdef HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS
+if (cc.context_init &&
virtio_gpu_context_init_enabled(g->parent_obj.conf)) {
+virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
+ cc.context_init,
+ cc.nlen,
+ cc.debug_name);
+return;
+}
+#endif
+
+virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
}
static void virgl_cmd_context_destroy(VirtIOGPU *g,
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index b016d3bac8..8b2f4c6be3 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1619,6 +1619,10 @@ static Property virtio_gpu_properties[] = {
DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
+#ifdef HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS
+DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
+VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, true),
+#endif
DEFINE_PROP_END_OF_LIST(),
};
--
2.25.1
[PATCH v6 02/11] virtio-gpu: Configure new feature flag context_create_with_flags for virglrenderer
Configure a new feature flag (context_create_with_flags) for
virglrenderer.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
Changes in v6:
- Move macros configurations under virgl.found() and rename
HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS.
meson.build | 4
1 file changed, 4 insertions(+)
diff --git a/meson.build b/meson.build
index ec01f8b138..ea52ef1b9c 100644
--- a/meson.build
+++ b/meson.build
@@ -1050,6 +1050,10 @@ if not get_option('virglrenderer').auto() or have_system
or have_vhost_user_gpu
cc.has_member('struct
virgl_renderer_resource_info_ext', 'd3d_tex2d',
prefix: '#include ',
dependencies: virgl))
+config_host_data.set('HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS',
+
cc.has_function('virgl_renderer_context_create_with_flags',
+ prefix: '#include ',
+ dependencies: virgl))
endif
endif
rutabaga = not_found
--
2.25.1
[PATCH v6 01/11] linux-headers: Update to kernel headers to add venus capset
Sync up kernel headers to update venus macro till they are merged into
mainline.
Signed-off-by: Huang Rui
---
Changes in v6:
- Venus capset is applied in kernel, so update it in qemu for future use.
https://lore.kernel.org/lkml/b79dcf75-c9e8-490e-644f-3b97d95f7...@collabora.com/
https://cgit.freedesktop.org/drm-misc/commit/?id=216d86b9a430f3280e5b631c51e6fd1a7774cfa0
include/standard-headers/linux/virtio_gpu.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/standard-headers/linux/virtio_gpu.h
b/include/standard-headers/linux/virtio_gpu.h
index 2da48d3d4c..2db643ed8f 100644
--- a/include/standard-headers/linux/virtio_gpu.h
+++ b/include/standard-headers/linux/virtio_gpu.h
@@ -309,6 +309,8 @@ struct virtio_gpu_cmd_submit {
#define VIRTIO_GPU_CAPSET_VIRGL 1
#define VIRTIO_GPU_CAPSET_VIRGL2 2
+/* 3 is reserved for gfxstream */
+#define VIRTIO_GPU_CAPSET_VENUS 4
/* VIRTIO_GPU_CMD_GET_CAPSET_INFO */
struct virtio_gpu_get_capset_info {
--
2.25.1
Re: QEMU Virtio GPU features status & roadmap?
On Wed, Nov 08, 2023 at 07:07:43PM +0800, Marc-André Lureau wrote: > Hi > > On Wed, Nov 8, 2023 at 1:04 PM Antonio Caggiano > wrote: > > > > Hi Hans, > > > > +cc Gert and Dmitry > > > > On 17/10/2023 02:48, Hans de Ruiter wrote: > > > Hi, > > > > > > I'm working on Virtio GPU drivers for AmigaOS, and would like to know > > > what features are currently stable enough to use. Looking at the master > > > QEMU branch, both Virgl and blob resources are supported, but NOT at the > > > same time. Is the ability to use both simultaneously coming soon? > > > > > > > Mmh, well, they should be compatible, I'll try sending a patch. > > > > > Also, what's the state of Venus/Vulkan support? Surveying various > > > forks/branches, it looks very experimental and subject to change. > > > > > > > I believe this is quite stable now: > > https://gitlab.freedesktop.org/virgl/venus-protocol/-/issues/5 > > The last patch series for QEMU is from Huang Rui: > https://patchew.org/QEMU/2023091530.24064-1-ray.hu...@amd.com/ I am working on V6, and will send them out very soon. Thanks, Ray > > > > > Virglrenderer 1.0.0 has been released as well. I wonder if that requires > > any change in QEMU. Gert or Dmitry might know the answer. > > No changes required afaik. > > > > > > I have the added difficulty that the AmigaOS Picasso96 driver API > > > expects direct CPU access to all of VRAM, and likes to peek/poke > > > directly into the bitmaps. That's clearly not possible without blob > > > resources, or shared memory (not entirely sure what the shared memory > > > feature is for). This is why I want to know what features are stable or > > > coming soon. > > > > > > > The shared memory feature is just a requirement which enables support > > for blob resources. > > Now that we are in freeze, we won't merge new features until the end > of this year / next year. But we can already plan / test / review etc. > > Antonio, do you have your work coordinated with Huang? > > Huang, are you going to send a new version of the venus series? > > It would be great to include docs/system/devices/virtio-gpu.rst > updates too. It's getting difficult to follow the various ways > virtio-gpu can be used nowadays. > > thanks > > -- > Marc-André Lureau
Re: [QEMU PATCH v5 11/13] virtio-gpu: Support Venus capset
On Tue, Sep 19, 2023 at 05:02:36PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Fri, Sep 15, 2023 at 3:14 PM Huang Rui wrote:
> >
> > From: Antonio Caggiano
> >
> > Add support for the Venus capset, which enables Vulkan support through
> > the Venus Vulkan driver for virtio-gpu.
> >
> > Signed-off-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > V4 -> V5:
> > - Send kernel patch to define VIRTIO_GPU_CAPSET_VENUS and will use
> > another patch to sync up linux headers. (Akihiko)
> > -
> > https://lore.kernel.org/lkml/20230915105918.3763061-1-ray.hu...@amd.com/
>
> Ok but in the meantime, you should have that header update patch in
> the series too, otherwise we can't compile it :)
>
In fact, it's in my repo. :-)
I am waiting for it to be merged into kernel mainline and then update the
commit id.
https://gitlab.freedesktop.org/rui/qemu-xen/-/commit/4ae9d078f9242890769c98162caf32f95df42529
I will include it in next series.
Thanks,
Ray
> thanks
>
> >
> > hw/display/virtio-gpu-virgl.c | 21 +
> > 1 file changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 8a017dbeb4..7f95490e90 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -437,6 +437,11 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
> > virgl_renderer_get_cap_set(resp.capset_id,
> > _max_version,
> > _max_size);
> > +} else if (info.capset_index == 2) {
> > +resp.capset_id = VIRTIO_GPU_CAPSET_VENUS;
> > +virgl_renderer_get_cap_set(resp.capset_id,
> > + _max_version,
> > + _max_size);
> > } else {
> > resp.capset_max_version = 0;
> > resp.capset_max_size = 0;
> > @@ -901,10 +906,18 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> >
> > int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
> > {
> > -uint32_t capset2_max_ver, capset2_max_size;
> > +uint32_t capset2_max_ver, capset2_max_size, num_capsets;
> > +num_capsets = 1;
> > +
> > virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
> > - _max_ver,
> > - _max_size);
> > + _max_ver,
> > + _max_size);
> > +num_capsets += capset2_max_ver ? 1 : 0;
> > +
> > +virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
> > + _max_ver,
> > + _max_size);
> > +num_capsets += capset2_max_size ? 1 : 0;
> >
> > -return capset2_max_ver ? 2 : 1;
> > +return num_capsets;
> > }
> > --
> > 2.34.1
> >
> >
>
>
> --
> Marc-André Lureau
Re: [QEMU PATCH v5 10/13] virtio-gpu: Resource UUID
On Tue, Sep 19, 2023 at 05:00:05PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Fri, Sep 15, 2023 at 3:14 PM Huang Rui wrote:
> >
> > From: Antonio Caggiano
> >
> > Enable resource UUID feature and implement command resource assign UUID.
> > This is done by introducing a hash table to map resource IDs to their
> > UUIDs.
> >
> > Signed-off-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > V4 -> V5:
> > - Add virtio migration handling for uuid (Akihiko)
> > - Adjust sequence to allocate gpu resource before virglrender resource
> > creation (Akihiko)
> > - Clean up (Akihiko)
> >
> > hw/display/trace-events| 1 +
> > hw/display/virtio-gpu-base.c | 2 ++
> > hw/display/virtio-gpu-virgl.c | 21
> > hw/display/virtio-gpu.c| 58 ++
> > include/hw/virtio/virtio-gpu.h | 6
> > 5 files changed, 88 insertions(+)
> >
> > diff --git a/hw/display/trace-events b/hw/display/trace-events
> > index 2336a0ca15..54d6894c59 100644
> > --- a/hw/display/trace-events
> > +++ b/hw/display/trace-events
> > @@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t
> > size) "res 0x%x, size %" P
> > virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
> > +virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
> > diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
> > index 4f2b0ba1f3..f44388715c 100644
> > --- a/hw/display/virtio-gpu-base.c
> > +++ b/hw/display/virtio-gpu-base.c
> > @@ -236,6 +236,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev,
> > uint64_t features,
> > features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
> > }
> >
> > +features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
>
> This changes what is exposed to the guest. We should have an option
> for it, and set it to false on older machine types (similar to what is
> done for edid).
>
Did you mean we can add "resource_uuid" in virtio_gpu_properties[] like
below, user can set it to false on older types with the param?
DEFINE_PROP_BIT("resource_uuid", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_RESOURCE_UUID, true);
> > +
> > return features;
> > }
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 563a6f2f58..8a017dbeb4 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -36,11 +36,20 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
> > {
> > struct virtio_gpu_resource_create_2d c2d;
> > struct virgl_renderer_resource_create_args args;
> > +struct virtio_gpu_simple_resource *res;
> >
> > VIRTIO_GPU_FILL_CMD(c2d);
> > trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
> > c2d.width, c2d.height);
> >
> > +res = g_new0(struct virtio_gpu_simple_resource, 1);
> > +if (!res) {
>
> needless OOM here too
>
> > +cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
> > +return;
> > +}
> > +res->resource_id = c2d.resource_id;
> > +QTAILQ_INSERT_HEAD(>reslist, res, next);
> > +
> > args.handle = c2d.resource_id;
> > args.target = 2;
> > args.format = c2d.format;
> > @@ -60,11 +69,20 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> > {
> > struct virtio_gpu_resource_create_3d c3d;
> > struct virgl_renderer_resource_create_args args;
> > +struct virtio_gpu_simple_resource *res;
> >
> > VIRTIO_GPU_FILL_CMD(c3d);
> > trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
> > c3d.width, c3d.height, c3d.depth);
> >
> > +res = g_new0(struct virtio_gpu_simple_resource, 1);
> > +if (!res) {
>
> same
>
> > +cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
> > +return;
> > +}
> > +res->resource_id = c3d.resource_id;
> > +QTAILQ_INSERT_HEAD(&g
Re: [QEMU PATCH v5 09/13] virtio-gpu: Handle resource blob commands
On Tue, Sep 19, 2023 at 04:44:01PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Fri, Sep 15, 2023 at 3:14 PM Huang Rui wrote:
> >
> > From: Antonio Caggiano
> >
> > 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
> > Signed-off-by: Dmitry Osipenko
> > Signed-off-by: Xenia Ragiadakou
> > Signed-off-by: Huang Rui
> > ---
> >
> > V4 -> V5:
> > - Use memory_region_init_ram_ptr() instead of
> > memory_region_init_ram_device_ptr() (Akihiko)
> >
> > 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..563a6f2f58 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(, NULL, 0);
> > }
> >
> > +static void virgl_resource_destroy(VirtIOGPU *g,
> > + struct virtio_gpu_simple_resource *res)
> > +{
> > +if (!res)
> > +return;
> > +
>
> QEMU coding style imposes braces
>
Thanks for reminder.
> > +QTAILQ_REMOVE(>reslist, res, next);
> > +
> > +virtio_gpu_cleanup_mapping_iov(g, res->iov, res->iov_cnt);
> > +g_free(res->addrs);
> > +
> > +g_free(res);
>
> If you embed virtio_gpu_simple_resource in a new struct, we should
> instead call the existing virtio_gpu_resource_destroy() I guess.
Yes, but I didn't call virtio_gpu_resource_destroy() here, I am using the
virgl_resource_destroy() and the input should be the virgl resource in next
version. May I know whether I miss understood your point?
>
> > +}
> > +
> > 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,
> > _iovs,
> > _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();
> > +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",
> > + __
Re: [QEMU PATCH v5 05/13] virtio-gpu: Configure context init for virglrenderer
On Tue, Sep 19, 2023 at 04:17:43PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Fri, Sep 15, 2023 at 6:16 PM Huang Rui wrote:
> >
> > Configure context init feature flag for virglrenderer.
> >
> > Originally-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > V4 -> V5:
> > - Inverted patch 5 and 6 because we should configure
> > HAVE_VIRGL_CONTEXT_INIT firstly. (Philippe)
> >
> > meson.build | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/meson.build b/meson.build
> > index 98e68ef0b1..ff20d3c249 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1068,6 +1068,10 @@ if not get_option('virglrenderer').auto() or
> > have_system or have_vhost_user_gpu
> > prefix: '#include
> > ',
> > dependencies: virgl))
> >endif
> > + config_host_data.set('HAVE_VIRGL_CONTEXT_INIT',
> > +
> > cc.has_function('virgl_renderer_context_create_with_flags',
> > + prefix: '#include
> > ',
> > + dependencies: virgl))
>
> Move it under the "if virgl.found()" block above.
>
> I suggest to name it after what is actually checked:
> HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS for ex
>
OK, will update it in V6.
Thanks,
Ray
> > endif
> > blkio = not_found
> > if not get_option('blkio').auto() or have_block
> > --
> > 2.34.1
> >
> >
>
>
> --
> Marc-André Lureau
Re: [QEMU PATCH v5 10/13] virtio-gpu: Resource UUID
On Sat, Sep 16, 2023 at 12:48:14AM +0800, Akihiko Odaki wrote:
> On 2023/09/15 20:11, Huang Rui wrote:
> > From: Antonio Caggiano
> >
> > Enable resource UUID feature and implement command resource assign UUID.
> > This is done by introducing a hash table to map resource IDs to their
> > UUIDs.
> >
> > Signed-off-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > V4 -> V5:
> > - Add virtio migration handling for uuid (Akihiko)
> > - Adjust sequence to allocate gpu resource before virglrender resource
> >creation (Akihiko)
> > - Clean up (Akihiko)
> >
> > hw/display/trace-events| 1 +
> > hw/display/virtio-gpu-base.c | 2 ++
> > hw/display/virtio-gpu-virgl.c | 21
> > hw/display/virtio-gpu.c| 58 ++
> > include/hw/virtio/virtio-gpu.h | 6
> > 5 files changed, 88 insertions(+)
> >
> > diff --git a/hw/display/trace-events b/hw/display/trace-events
> > index 2336a0ca15..54d6894c59 100644
> > --- a/hw/display/trace-events
> > +++ b/hw/display/trace-events
> > @@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t
> > size) "res 0x%x, size %" P
> > virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
> > +virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
> > diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
> > index 4f2b0ba1f3..f44388715c 100644
> > --- a/hw/display/virtio-gpu-base.c
> > +++ b/hw/display/virtio-gpu-base.c
> > @@ -236,6 +236,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev,
> > uint64_t features,
> > features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
> > }
> >
> > +features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
> > +
> > return features;
> > }
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 563a6f2f58..8a017dbeb4 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -36,11 +36,20 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
> > {
> > struct virtio_gpu_resource_create_2d c2d;
> > struct virgl_renderer_resource_create_args args;
> > +struct virtio_gpu_simple_resource *res;
> >
> > VIRTIO_GPU_FILL_CMD(c2d);
> > trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
> > c2d.width, c2d.height);
> >
> > +res = g_new0(struct virtio_gpu_simple_resource, 1);
> > +if (!res) {
> > +cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
> > +return;
> > +}
> > +res->resource_id = c2d.resource_id;
> > +QTAILQ_INSERT_HEAD(>reslist, res, next);
> > +
>
> The struct virtio_gpu_simple_resource for a resource created with
> virgl_cmd_create_resource_2d() and virgl_resource_attach_backing() will
> not have iov and iov_cnt set, which is inconsistent with
> virgl_cmd_resource_create_blob().
>
OK, so we should find out the resource in virgl_resource_attach_backing(),
and set the related iov and iov_cnt for this resource to align with blob
memory.
> > args.handle = c2d.resource_id;
> > args.target = 2;
> > args.format = c2d.format;
> > @@ -60,11 +69,20 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> > {
> > struct virtio_gpu_resource_create_3d c3d;
> > struct virgl_renderer_resource_create_args args;
> > +struct virtio_gpu_simple_resource *res;
> >
> > VIRTIO_GPU_FILL_CMD(c3d);
> > trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
> > c3d.width, c3d.height, c3d.depth);
> >
> > +res = g_new0(struct virtio_gpu_simple_resource, 1);
> > +if (!res) {
> > +cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
> > +return;
> > +}
> > +res->resource_id = c3d.resource_id;
> > +QTAILQ_INSERT_HEAD(>reslist, res, next);
> > +
> > args.handle = c3d.resource_
Re: [QEMU PATCH v5 09/13] virtio-gpu: Handle resource blob commands
On Wed, Sep 20, 2023 at 01:54:03PM +0800, Akihiko Odaki wrote:
> On 2023/09/20 14:50, Huang Rui wrote:
> > On Sat, Sep 16, 2023 at 12:37:29AM +0800, Akihiko Odaki wrote:
> >> On 2023/09/16 1:04, Akihiko Odaki wrote:
> >>> On 2023/09/15 20:11, Huang Rui wrote:
> >>>> From: Antonio Caggiano
> >>>>
> >>>> 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
> >>>> Signed-off-by: Dmitry Osipenko
> >>>> Signed-off-by: Xenia Ragiadakou
> >>>> Signed-off-by: Huang Rui
> >>>> ---
> >>>>
> >>>> V4 -> V5:
> >>>> - Use memory_region_init_ram_ptr() instead of
> >>>> memory_region_init_ram_device_ptr() (Akihiko)
> >>>>
> >>>> 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..563a6f2f58 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(, NULL, 0);
> >>>> }
> >>>> +static void virgl_resource_destroy(VirtIOGPU *g,
> >>>> + struct virtio_gpu_simple_resource
> >>>> *res)
> >>>> +{
> >>>> + if (!res)
> >>>> + return;
> >>>> +
> >>>> + QTAILQ_REMOVE(>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,
> >>>> _iovs,
> >>>> _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);
> >>
> >> This may leak memory region.
> >
> > The memory region should be freed under virgl_cmd_resource_unmap_blob()
> > which is calling memory_region_del_subregion(>hostmem, res->region).
> > Because this region is created by map_blob(). Do we have the case to call
> > virgl_cmd_resource_unref() without calling virgl_cmd_resource_unmap_blob()
> > for blob memory?
>
> Calling virgl_cmd_resource_unmap_blob() and virgl_cmd_resource_unref()
> in order is a guest's responsibility, and we are required to prepare for
> broken guests.
OK, no problem. I will update this in V6.
Thanks,
Ray
Re: [QEMU PATCH v5 09/13] virtio-gpu: Handle resource blob commands
On Sat, Sep 16, 2023 at 12:37:29AM +0800, Akihiko Odaki wrote:
> On 2023/09/16 1:04, Akihiko Odaki wrote:
> > On 2023/09/15 20:11, Huang Rui wrote:
> >> From: Antonio Caggiano
> >>
> >> 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
> >> Signed-off-by: Dmitry Osipenko
> >> Signed-off-by: Xenia Ragiadakou
> >> Signed-off-by: Huang Rui
> >> ---
> >>
> >> V4 -> V5:
> >> - Use memory_region_init_ram_ptr() instead of
> >> memory_region_init_ram_device_ptr() (Akihiko)
> >>
> >> 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..563a6f2f58 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(, NULL, 0);
> >> }
> >> +static void virgl_resource_destroy(VirtIOGPU *g,
> >> + struct virtio_gpu_simple_resource
> >> *res)
> >> +{
> >> + if (!res)
> >> + return;
> >> +
> >> + QTAILQ_REMOVE(>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,
> >> _iovs,
> >> _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);
>
> This may leak memory region.
The memory region should be freed under virgl_cmd_resource_unmap_blob()
which is calling memory_region_del_subregion(>hostmem, res->region).
Because this region is created by map_blob(). Do we have the case to call
virgl_cmd_resource_unref() without calling virgl_cmd_resource_unmap_blob()
for blob memory?
Thanks,
Ray
Re: [QEMU PATCH v5 09/13] virtio-gpu: Handle resource blob commands
On Sat, Sep 16, 2023 at 12:04:17AM +0800, Akihiko Odaki wrote:
> On 2023/09/15 20:11, Huang Rui wrote:
> > From: Antonio Caggiano
> >
> > 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
> > Signed-off-by: Dmitry Osipenko
> > Signed-off-by: Xenia Ragiadakou
> > Signed-off-by: Huang Rui
> > ---
> >
> > V4 -> V5:
> > - Use memory_region_init_ram_ptr() instead of
> >memory_region_init_ram_device_ptr() (Akihiko)
> >
> > 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..563a6f2f58 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(, NULL, 0);
> > }
> >
> > +static void virgl_resource_destroy(VirtIOGPU *g,
> > + struct virtio_gpu_simple_resource *res)
> > +{
> > +if (!res)
> > +return;
> > +
> > +QTAILQ_REMOVE(>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,
> > _iovs,
> > _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();
> > +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);
> >
Re: [QEMU PATCH v5 06/13] virtio-gpu: Support context init feature with virglrenderer
On Mon, Sep 18, 2023 at 02:07:25PM +0800, Akihiko Odaki wrote:
> On 2023/09/18 14:43, Huang Rui wrote:
> > On Sun, Sep 17, 2023 at 01:49:19PM +0800, Akihiko Odaki wrote:
> >> On 2023/09/17 14:45, Huang Rui wrote:
> >>> On Sat, Sep 16, 2023 at 06:42:04PM +0800, Akihiko Odaki wrote:
> >>>> On 2023/09/16 19:32, Huang Rui wrote:
> >>>>> On Fri, Sep 15, 2023 at 11:20:46PM +0800, Akihiko Odaki wrote:
> >>>>>> On 2023/09/15 20:11, Huang Rui wrote:
> >>>>>>> Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
> >>>>>>> feature flags.
> >>>>>>> We would like to enable the feature with virglrenderer, so add to
> >>>>>>> create
> >>>>>>> virgl renderer context with flags using context_id when valid.
> >>>>>>>
> >>>>>>> Originally-by: Antonio Caggiano
> >>>>>>> Signed-off-by: Huang Rui
> >>>>>>> ---
> >>>>>>>
> >>>>>>> V4 -> V5:
> >>>>>>> - Inverted patch 5 and 6 because we should configure
> >>>>>>> HAVE_VIRGL_CONTEXT_INIT firstly. (Philippe)
> >>>>>>>
> >>>>>>> hw/display/virtio-gpu-virgl.c | 13 +++--
> >>>>>>> hw/display/virtio-gpu.c | 2 ++
> >>>>>>> 2 files changed, 13 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/hw/display/virtio-gpu-virgl.c
> >>>>>>> b/hw/display/virtio-gpu-virgl.c
> >>>>>>> index 8bb7a2c21f..312953ec16 100644
> >>>>>>> --- a/hw/display/virtio-gpu-virgl.c
> >>>>>>> +++ b/hw/display/virtio-gpu-virgl.c
> >>>>>>> @@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU
> >>>>>>> *g,
> >>>>>>> trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
> >>>>>>> cc.debug_name);
> >>>>>>>
> >>>>>>> -virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
> >>>>>>> - cc.debug_name);
> >>>>>>> +if (cc.context_init) {
> >>>>>>> +#ifdef HAVE_VIRGL_CONTEXT_INIT
> >>>>>>> +virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
> >>>>>>> + cc.context_init,
> >>>>>>> + cc.nlen,
> >>>>>>> + cc.debug_name);
> >>>>>>> +return;
> >>>>>>> +#endif
> >>>>>>
> >>>>>> This should deal with the case when context_init is set while
> >>>>>> HAVE_VIRGL_CONTEXT_INIT is not defined.
> >>>>>
> >>>>> Actually, I received the comment below before:
> >>>>>
> >>>>> https://lore.kernel.org/qemu-devel/32588d0e-a1f2-30c4-5e9f-e6e7c4190...@linaro.org/
> >>>>>
> >>>>> At original patch set, I have the case while HAVE_VIRGL_CONTEXT_INIT is
> >>>>> set
> >>>>> but HAVE_VIRGL_CONTEXT_INIT is not defined. But I think we may encounter
> >>>>> the case that virgl_renderer_context_create_with_flags is not defined in
> >>>>> virglrenderer early version. Should I bring the error message back?
> >>>>>
> >>>>> Thanks,
> >>>>> Ray
> >>>>
> >>>> I suggest checking VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED instead of
> >>>> reporting an error here. Perhaps it may be easier to add #ifdef around:
> >>>>> +DEFINE_PROP_BIT("context_init", VirtIOGPU,
> >>>> parent_obj.conf.flags,
> >>>>> +VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, false),
> >>>
> >>> How about below changes: >
> >>> ---
> >>> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> >>> index 8bb7a2c21f..54a3cfe136 100644
> >>> --- a/hw/display/virtio-gpu-virgl.c
> >>> +++ b/hw/displ
Re: [QEMU PATCH v5 06/13] virtio-gpu: Support context init feature with virglrenderer
On Sun, Sep 17, 2023 at 01:49:19PM +0800, Akihiko Odaki wrote:
> On 2023/09/17 14:45, Huang Rui wrote:
> > On Sat, Sep 16, 2023 at 06:42:04PM +0800, Akihiko Odaki wrote:
> >> On 2023/09/16 19:32, Huang Rui wrote:
> >>> On Fri, Sep 15, 2023 at 11:20:46PM +0800, Akihiko Odaki wrote:
> >>>> On 2023/09/15 20:11, Huang Rui wrote:
> >>>>> Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
> >>>>> feature flags.
> >>>>> We would like to enable the feature with virglrenderer, so add to create
> >>>>> virgl renderer context with flags using context_id when valid.
> >>>>>
> >>>>> Originally-by: Antonio Caggiano
> >>>>> Signed-off-by: Huang Rui
> >>>>> ---
> >>>>>
> >>>>> V4 -> V5:
> >>>>>- Inverted patch 5 and 6 because we should configure
> >>>>> HAVE_VIRGL_CONTEXT_INIT firstly. (Philippe)
> >>>>>
> >>>>> hw/display/virtio-gpu-virgl.c | 13 +++--
> >>>>> hw/display/virtio-gpu.c | 2 ++
> >>>>> 2 files changed, 13 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/hw/display/virtio-gpu-virgl.c
> >>>>> b/hw/display/virtio-gpu-virgl.c
> >>>>> index 8bb7a2c21f..312953ec16 100644
> >>>>> --- a/hw/display/virtio-gpu-virgl.c
> >>>>> +++ b/hw/display/virtio-gpu-virgl.c
> >>>>> @@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
> >>>>> trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
> >>>>> cc.debug_name);
> >>>>>
> >>>>> -virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
> >>>>> - cc.debug_name);
> >>>>> +if (cc.context_init) {
> >>>>> +#ifdef HAVE_VIRGL_CONTEXT_INIT
> >>>>> +virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
> >>>>> + cc.context_init,
> >>>>> + cc.nlen,
> >>>>> + cc.debug_name);
> >>>>> +return;
> >>>>> +#endif
> >>>>
> >>>> This should deal with the case when context_init is set while
> >>>> HAVE_VIRGL_CONTEXT_INIT is not defined.
> >>>
> >>> Actually, I received the comment below before:
> >>>
> >>> https://lore.kernel.org/qemu-devel/32588d0e-a1f2-30c4-5e9f-e6e7c4190...@linaro.org/
> >>>
> >>> At original patch set, I have the case while HAVE_VIRGL_CONTEXT_INIT is
> >>> set
> >>> but HAVE_VIRGL_CONTEXT_INIT is not defined. But I think we may encounter
> >>> the case that virgl_renderer_context_create_with_flags is not defined in
> >>> virglrenderer early version. Should I bring the error message back?
> >>>
> >>> Thanks,
> >>> Ray
> >>
> >> I suggest checking VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED instead of
> >> reporting an error here. Perhaps it may be easier to add #ifdef around:
> >> > +DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
> >> > +VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, false),
> >
> > How about below changes: >
> > ---
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 8bb7a2c21f..54a3cfe136 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -106,8 +106,15 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
> > trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
> > cc.debug_name);
> >
> > -virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
> > - cc.debug_name);
> > +if (cc.context_init && virtio_gpu_context_init_enabled(g->conf)) {
> > +virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
> > + cc.context_init,
> > + cc.nlen,
> > + cc.debug_name);
> > +return;
> > +}
> > +
> > +virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
> > }
> >
> > static void virgl_cmd_context_destroy(VirtIOGPU *g,
> > diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> > index be16efbd38..6ff2c8e92d 100644
> > --- a/hw/display/virtio-gpu.c
> > +++ b/hw/display/virtio-gpu.c
> > @@ -1508,6 +1508,10 @@ static Property virtio_gpu_properties[] = {
> > DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
> > VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
> > DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
> > +#ifdef HAVE_VIRGL_CONTEXT_INIT
> > +DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
> > +VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, true),
> > +#endif
> > DEFINE_PROP_END_OF_LIST(),
> > };
> >
>
> It looks better, but not having #ifdef around
> virgl_renderer_context_create_with_flags() will result in a link error
> with old virglrenderer.
Hmm, right, it seems that we have to have a "#ifdef" around here. Or do you
have any better idea?
Thanks,
Ray
Re: [QEMU PATCH v5 06/13] virtio-gpu: Support context init feature with virglrenderer
On Sat, Sep 16, 2023 at 06:42:04PM +0800, Akihiko Odaki wrote:
> On 2023/09/16 19:32, Huang Rui wrote:
> > On Fri, Sep 15, 2023 at 11:20:46PM +0800, Akihiko Odaki wrote:
> >> On 2023/09/15 20:11, Huang Rui wrote:
> >>> Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
> >>> feature flags.
> >>> We would like to enable the feature with virglrenderer, so add to create
> >>> virgl renderer context with flags using context_id when valid.
> >>>
> >>> Originally-by: Antonio Caggiano
> >>> Signed-off-by: Huang Rui
> >>> ---
> >>>
> >>> V4 -> V5:
> >>> - Inverted patch 5 and 6 because we should configure
> >>> HAVE_VIRGL_CONTEXT_INIT firstly. (Philippe)
> >>>
> >>>hw/display/virtio-gpu-virgl.c | 13 +++--
> >>>hw/display/virtio-gpu.c | 2 ++
> >>>2 files changed, 13 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> >>> index 8bb7a2c21f..312953ec16 100644
> >>> --- a/hw/display/virtio-gpu-virgl.c
> >>> +++ b/hw/display/virtio-gpu-virgl.c
> >>> @@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
> >>>trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
> >>>cc.debug_name);
> >>>
> >>> -virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
> >>> - cc.debug_name);
> >>> +if (cc.context_init) {
> >>> +#ifdef HAVE_VIRGL_CONTEXT_INIT
> >>> +virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
> >>> + cc.context_init,
> >>> + cc.nlen,
> >>> + cc.debug_name);
> >>> +return;
> >>> +#endif
> >>
> >> This should deal with the case when context_init is set while
> >> HAVE_VIRGL_CONTEXT_INIT is not defined.
> >
> > Actually, I received the comment below before:
> >
> > https://lore.kernel.org/qemu-devel/32588d0e-a1f2-30c4-5e9f-e6e7c4190...@linaro.org/
> >
> > At original patch set, I have the case while HAVE_VIRGL_CONTEXT_INIT is set
> > but HAVE_VIRGL_CONTEXT_INIT is not defined. But I think we may encounter
> > the case that virgl_renderer_context_create_with_flags is not defined in
> > virglrenderer early version. Should I bring the error message back?
> >
> > Thanks,
> > Ray
>
> I suggest checking VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED instead of
> reporting an error here. Perhaps it may be easier to add #ifdef around:
> > +DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
> > +VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, false),
How about below changes:
---
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 8bb7a2c21f..54a3cfe136 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -106,8 +106,15 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
cc.debug_name);
-virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
- cc.debug_name);
+if (cc.context_init && virtio_gpu_context_init_enabled(g->conf)) {
+virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
+ cc.context_init,
+ cc.nlen,
+ cc.debug_name);
+return;
+}
+
+virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
}
static void virgl_cmd_context_destroy(VirtIOGPU *g,
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index be16efbd38..6ff2c8e92d 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1508,6 +1508,10 @@ static Property virtio_gpu_properties[] = {
DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
+#ifdef HAVE_VIRGL_CONTEXT_INIT
+DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
+VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, true),
+#endif
DEFINE_PROP_END_OF_LIST(),
};
Re: [QEMU PATCH v5 06/13] virtio-gpu: Support context init feature with virglrenderer
On Sat, Sep 16, 2023 at 12:58:31AM +0800, Akihiko Odaki wrote:
> On 2023/09/15 20:11, Huang Rui wrote:
> > Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
> > feature flags.
> > We would like to enable the feature with virglrenderer, so add to create
> > virgl renderer context with flags using context_id when valid.
> >
> > Originally-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > V4 -> V5:
> > - Inverted patch 5 and 6 because we should configure
> >HAVE_VIRGL_CONTEXT_INIT firstly. (Philippe)
> >
> > hw/display/virtio-gpu-virgl.c | 13 +++--
> > hw/display/virtio-gpu.c | 2 ++
> > 2 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 8bb7a2c21f..312953ec16 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
> > trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
> > cc.debug_name);
> >
> > -virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
> > - cc.debug_name);
> > +if (cc.context_init) {
> > +#ifdef HAVE_VIRGL_CONTEXT_INIT
> > +virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
> > + cc.context_init,
> > + cc.nlen,
> > + cc.debug_name);
> > +return;
> > +#endif
> > +}
> > +
> > +virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
> > }
> >
> > static void virgl_cmd_context_destroy(VirtIOGPU *g,
> > diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
> > index 3e658f1fef..a66cbd9930 100644
> > --- a/hw/display/virtio-gpu.c
> > +++ b/hw/display/virtio-gpu.c
> > @@ -1506,6 +1506,8 @@ static Property virtio_gpu_properties[] = {
> > DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
> > VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
> > DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
> > +DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
> > +VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, false),
> > DEFINE_PROP_END_OF_LIST(),
> > };
> >
>
> I think it's more convenient if this feature is enabled by default.
Yes, I will update it in next version.
Thanks,
Ray
Re: [QEMU PATCH v5 06/13] virtio-gpu: Support context init feature with virglrenderer
On Fri, Sep 15, 2023 at 11:20:46PM +0800, Akihiko Odaki wrote:
> On 2023/09/15 20:11, Huang Rui wrote:
> > Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
> > feature flags.
> > We would like to enable the feature with virglrenderer, so add to create
> > virgl renderer context with flags using context_id when valid.
> >
> > Originally-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > V4 -> V5:
> > - Inverted patch 5 and 6 because we should configure
> >HAVE_VIRGL_CONTEXT_INIT firstly. (Philippe)
> >
> > hw/display/virtio-gpu-virgl.c | 13 +++--
> > hw/display/virtio-gpu.c | 2 ++
> > 2 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 8bb7a2c21f..312953ec16 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
> > trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
> > cc.debug_name);
> >
> > -virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
> > - cc.debug_name);
> > +if (cc.context_init) {
> > +#ifdef HAVE_VIRGL_CONTEXT_INIT
> > +virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
> > + cc.context_init,
> > + cc.nlen,
> > + cc.debug_name);
> > +return;
> > +#endif
>
> This should deal with the case when context_init is set while
> HAVE_VIRGL_CONTEXT_INIT is not defined.
Actually, I received the comment below before:
https://lore.kernel.org/qemu-devel/32588d0e-a1f2-30c4-5e9f-e6e7c4190...@linaro.org/
At original patch set, I have the case while HAVE_VIRGL_CONTEXT_INIT is set
but HAVE_VIRGL_CONTEXT_INIT is not defined. But I think we may encounter
the case that virgl_renderer_context_create_with_flags is not defined in
virglrenderer early version. Should I bring the error message back?
Thanks,
Ray
[QEMU PATCH v5 00/13] Support blob memory and venus on qemu
Hi all, Antonio Caggiano made the venus with QEMU on KVM platform last September[1]. This series are inherited from his original work to support the features of context init, hostmem, resource uuid, and blob resources for venus. At March of this year, we sent out the V1 version[2] for the review. But those series are included both xen and virtio gpu. Right now, we would like to divide into two parts, one is to continue the Antonio's work to upstream virtio-gpu support for blob memory and venus, and another is to upstream xen specific patches. This series is focusing on virtio-gpu, so we are marking as V4 version here to continue Antonio's patches[1]. And we will send xen specific patches separately, because they are hypervisor specific. Besides of QEMU, these supports also included virglrenderer[3][4] and mesa[5][6] as well. Right now, virglrenderer and mesa parts are all accepted by upstream. In this qemu version, we try to address the concerns around not proper cleanup during blob resource unmap and unref. Appreciate it if you have any commments. [1] https://lore.kernel.org/qemu-devel/20220926142422.22325-1-antonio.caggi...@collabora.com/ [2] V1: https://lore.kernel.org/qemu-devel/20230312092244.451465-1-ray.hu...@amd.com [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1068 [4] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1180 [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22108 [6] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23680 Please note the first 4 patches 1 -> 4 are inlcuded in these series because the series depends on them and not because we want them to be reviewed since they are already in the process of review through the "rutabaga_gfx + gfxstream" series. - https://lore.kernel.org/qemu-devel/20230829003629.410-1-gurchetansi...@chromium.org/ V4: https://lore.kernel.org/qemu-devel/20230831093252.2461282-1-ray.hu...@amd.com Changes from V4 (virtio gpu V4) to V5 - Inverted patch 5 and 6 because we should configure HAVE_VIRGL_CONTEXT_INIT firstly. - Validate owner of memory region to avoid slowing down DMA. - Use memory_region_init_ram_ptr() instead of memory_region_init_ram_device_ptr(). - Adjust sequence to allocate gpu resource before virglrender resource creation - Add virtio migration handling for uuid. - Send kernel patch to define VIRTIO_GPU_CAPSET_VENUS. https://lore.kernel.org/lkml/20230915105918.3763061-1-ray.hu...@amd.com/ - Add meson check to make sure unstable APIs defined from 0.9.0. Changes from V1 to V2 (virtio gpu V4) - 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(>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 and is allocated dynamically when the blob is mapped. Also, since the pointer can be used to indicate whether the blob is mapped, the explicite 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. - Add a patch to enable automatic deallocation of memory regions to resolve use-after-free memory corruption with a reference. References Demo with Venus: - https://static.sched.com/hosted_files/xen2023/3f/xen_summit_2023_virtgpu_demo.mp4 QEMU repository: - https://gitlab.freedesktop.org/rui/qemu-xen/-/commits/upstream-for-virtio-gpu Thanks, Ray Antonio Caggiano (6): virtio-gpu: CONTEXT_INIT feature virtio-gpu: blob prep virtio-gpu: Handle resource blob commands virtio-gpu: Resource UUID virtio-gpu: Support Venus capset virtio-gpu: Initialize Venus Dmitry Osipenko (1): virtio-gpu: Don't require udmabuf when blobs and virgl are enabled Dr. David Alan Gilbert (1): virtio: Add shared memory capability Gerd Hoffmann (1): virtio-gpu: hostmem Huang Rui (3): virtio-gpu: Configure context init for virglrenderer virtio-gpu: Support context init feature with virglrenderer virtio-gpu: Enable virglrenderer render server flag for venus Xenia Ragiadakou (1): softmmu/memory: enable automatic deallocation of memory regions hw/display/trace-events | 1 + hw/display/virtio-gpu-base.c | 5 + hw/display/virtio-gpu-pci.c | 14 ++ hw/display/virtio-gpu-virgl.c| 272 ++
[QEMU PATCH v5 09/13] virtio-gpu: Handle resource blob commands
From: Antonio Caggiano
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
Signed-off-by: Dmitry Osipenko
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
---
V4 -> V5:
- Use memory_region_init_ram_ptr() instead of
memory_region_init_ram_device_ptr() (Akihiko)
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..563a6f2f58 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(, NULL, 0);
}
+static void virgl_resource_destroy(VirtIOGPU *g,
+ struct virtio_gpu_simple_resource *res)
+{
+if (!res)
+return;
+
+QTAILQ_REMOVE(>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,
_iovs,
_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();
+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, >addrs, >iov,
+>iov_cnt);
+if (!ret) {
+g_free(res);
+cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+return;
+}
+}
+
+QTAILQ_INSERT_HEAD(>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(_args);
+if (ret) {
+virgl_resource_destroy(g, res);
+qemu_log_mask(LOG_GUEST_ERROR, "%s: virgl blob
[QEMU PATCH v5 11/13] virtio-gpu: Support Venus capset
From: Antonio Caggiano
Add support for the Venus capset, which enables Vulkan support through
the Venus Vulkan driver for virtio-gpu.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
V4 -> V5:
- Send kernel patch to define VIRTIO_GPU_CAPSET_VENUS and will use
another patch to sync up linux headers. (Akihiko)
- https://lore.kernel.org/lkml/20230915105918.3763061-1-ray.hu...@amd.com/
hw/display/virtio-gpu-virgl.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 8a017dbeb4..7f95490e90 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -437,6 +437,11 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
virgl_renderer_get_cap_set(resp.capset_id,
_max_version,
_max_size);
+} else if (info.capset_index == 2) {
+resp.capset_id = VIRTIO_GPU_CAPSET_VENUS;
+virgl_renderer_get_cap_set(resp.capset_id,
+ _max_version,
+ _max_size);
} else {
resp.capset_max_version = 0;
resp.capset_max_size = 0;
@@ -901,10 +906,18 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
{
-uint32_t capset2_max_ver, capset2_max_size;
+uint32_t capset2_max_ver, capset2_max_size, num_capsets;
+num_capsets = 1;
+
virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
- _max_ver,
- _max_size);
+ _max_ver,
+ _max_size);
+num_capsets += capset2_max_ver ? 1 : 0;
+
+virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
+ _max_ver,
+ _max_size);
+num_capsets += capset2_max_size ? 1 : 0;
-return capset2_max_ver ? 2 : 1;
+return num_capsets;
}
--
2.34.1
[QEMU PATCH v5 12/13] virtio-gpu: Initialize Venus
From: Antonio Caggiano
Request Venus when initializing VirGL.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
V4 -> V5:
- Add meson check to make sure unstable APIs defined from 0.9.0. (Antonio)
hw/display/virtio-gpu-virgl.c | 4
meson.build | 5 +
2 files changed, 9 insertions(+)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 7f95490e90..39c04d730c 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -887,6 +887,10 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
}
#endif
+#ifdef VIRGL_RENDERER_VENUS
+flags |= VIRGL_RENDERER_VENUS;
+#endif
+
ret = virgl_renderer_init(g, flags, _gpu_3d_cbs);
if (ret != 0) {
error_report("virgl could not be initialized: %d", ret);
diff --git a/meson.build b/meson.build
index f7b744ab82..e4004d05b1 100644
--- a/meson.build
+++ b/meson.build
@@ -1076,6 +1076,11 @@ if not get_option('virglrenderer').auto() or have_system
or have_vhost_user_gpu
cc.has_function('virgl_renderer_resource_create_blob',
prefix: '#include ',
dependencies: virgl))
+ if virgl.version().version_compare('>= 0.9.0') and
virgl.version().version_compare('< 1.0.0')
+message('Enabling virglrenderer unstable APIs')
+virgl = declare_dependency(compile_args: '-DVIRGL_RENDERER_UNSTABLE_APIS',
+ dependencies: virgl)
+ endif
endif
blkio = not_found
if not get_option('blkio').auto() or have_block
--
2.34.1
[QEMU PATCH v5 08/13] virtio-gpu: Don't require udmabuf when blobs and virgl are enabled
From: Dmitry Osipenko
The udmabuf usage is mandatory when virgl is disabled and blobs feature
enabled in the Qemu machine configuration. If virgl and blobs are enabled,
then udmabuf requirement is optional. Since udmabuf isn't widely supported
by a popular Linux distros today, let's relax the udmabuf requirement for
blobs=on,virgl=on. Now, a full-featured virtio-gpu acceleration is
available to Qemu users without a need to have udmabuf available in the
system.
Reviewed-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
Signed-off-by: Huang Rui
---
hw/display/virtio-gpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index a66cbd9930..5b7a7eab4f 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1361,7 +1361,8 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error
**errp)
VirtIOGPU *g = VIRTIO_GPU(qdev);
if (virtio_gpu_blob_enabled(g->parent_obj.conf)) {
-if (!virtio_gpu_have_udmabuf()) {
+if (!virtio_gpu_virgl_enabled(g->parent_obj.conf) &&
+!virtio_gpu_have_udmabuf()) {
error_setg(errp, "cannot enable blob resources without udmabuf");
return;
}
--
2.34.1
[QEMU PATCH v5 10/13] virtio-gpu: Resource UUID
From: Antonio Caggiano
Enable resource UUID feature and implement command resource assign UUID.
This is done by introducing a hash table to map resource IDs to their
UUIDs.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
V4 -> V5:
- Add virtio migration handling for uuid (Akihiko)
- Adjust sequence to allocate gpu resource before virglrender resource
creation (Akihiko)
- Clean up (Akihiko)
hw/display/trace-events| 1 +
hw/display/virtio-gpu-base.c | 2 ++
hw/display/virtio-gpu-virgl.c | 21
hw/display/virtio-gpu.c| 58 ++
include/hw/virtio/virtio-gpu.h | 6
5 files changed, 88 insertions(+)
diff --git a/hw/display/trace-events b/hw/display/trace-events
index 2336a0ca15..54d6894c59 100644
--- a/hw/display/trace-events
+++ b/hw/display/trace-events
@@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t size)
"res 0x%x, size %" P
virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
+virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index 4f2b0ba1f3..f44388715c 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -236,6 +236,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
}
+features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
+
return features;
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 563a6f2f58..8a017dbeb4 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -36,11 +36,20 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_2d c2d;
struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_simple_resource *res;
VIRTIO_GPU_FILL_CMD(c2d);
trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
c2d.width, c2d.height);
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+return;
+}
+res->resource_id = c2d.resource_id;
+QTAILQ_INSERT_HEAD(>reslist, res, next);
+
args.handle = c2d.resource_id;
args.target = 2;
args.format = c2d.format;
@@ -60,11 +69,20 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_3d c3d;
struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_simple_resource *res;
VIRTIO_GPU_FILL_CMD(c3d);
trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
c3d.width, c3d.height, c3d.depth);
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+return;
+}
+res->resource_id = c3d.resource_id;
+QTAILQ_INSERT_HEAD(>reslist, res, next);
+
args.handle = c3d.resource_id;
args.target = c3d.target;
args.format = c3d.format;
@@ -682,6 +700,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
/* TODO add security */
virgl_cmd_ctx_detach_resource(g, cmd);
break;
+case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
+virtio_gpu_resource_assign_uuid(g, cmd);
+break;
case VIRTIO_GPU_CMD_GET_CAPSET_INFO:
virgl_cmd_get_capset_info(g, cmd);
break;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index cc4c1f81bb..44414c1c5e 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -966,6 +966,38 @@ virtio_gpu_resource_detach_backing(VirtIOGPU *g,
virtio_gpu_cleanup_mapping(g, res);
}
+void virtio_gpu_resource_assign_uuid(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_simple_resource *res;
+struct virtio_gpu_resource_assign_uuid assign;
+struct virtio_gpu_resp_resource_uuid resp;
+QemuUUID *uuid;
+
+VIRTIO_GPU_FILL_CMD(assign);
+virtio_gpu_bswap_32(, sizeof(assign));
+trace_virtio_gpu_cmd_res_assign_uuid(assign.resource_id);
+
+res = virtio_gpu_find_check_resource(g, assign.resource_id, false,
__func__, >error);
+if (!res) {
+return;
+}
+
+memset(, 0, sizeof(resp));
+resp.hdr.type = VIRTIO_GPU_RESP_OK_RESOURCE_UUID;
+
+uuid = g_hash_table_lookup(g->resource_uuids,
GUINT_TO_POINTER(assign.resource_id));
+if (!uuid) {
+uuid = g
[QEMU PATCH v5 13/13] virtio-gpu: Enable virglrenderer render server flag for venus
Venus in virglrenderer has required render server support. Signed-off-by: Huang Rui --- hw/display/virtio-gpu-virgl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c index 39c04d730c..65ffce85a8 100644 --- a/hw/display/virtio-gpu-virgl.c +++ b/hw/display/virtio-gpu-virgl.c @@ -888,7 +888,7 @@ int virtio_gpu_virgl_init(VirtIOGPU *g) #endif #ifdef VIRGL_RENDERER_VENUS -flags |= VIRGL_RENDERER_VENUS; +flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER; #endif ret = virgl_renderer_init(g, flags, _gpu_3d_cbs); -- 2.34.1
[QEMU PATCH v5 07/13] softmmu/memory: enable automatic deallocation of memory regions
From: Xenia Ragiadakou
When the memory region has a different life-cycle from that of her parent,
could be automatically released, once has been unparent and once all of her
references have gone away, via the object's free callback.
However, currently, references to the memory region are held by its owner
without first incrementing the memory region object's reference count.
As a result, the automatic deallocation of the object, not taking into
account those references, results in use-after-free memory corruption.
This patch increases the reference count of an owned memory region object
on each memory_region_ref() and decreases it on each memory_region_unref().
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
---
V4 -> V5:
- ref/unref only owned memory regions (Akihiko)
softmmu/memory.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/softmmu/memory.c b/softmmu/memory.c
index 7d9494ce70..15e1699750 100644
--- a/softmmu/memory.c
+++ b/softmmu/memory.c
@@ -1800,6 +1800,9 @@ void memory_region_ref(MemoryRegion *mr)
/* MMIO callbacks most likely will access data that belongs
* to the owner, hence the need to ref/unref the owner whenever
* the memory region is in use.
+ * Likewise, the owner keeps references to the memory region,
+ * hence the need to ref/unref the memory region object to prevent
+ * its automatic deallocation while still referenced by its owner.
*
* The memory region is a child of its owner. As long as the
* owner doesn't call unparent itself on the memory region,
@@ -1808,6 +1811,7 @@ void memory_region_ref(MemoryRegion *mr)
* we do not ref/unref them because it slows down DMA sensibly.
*/
if (mr && mr->owner) {
+object_ref(OBJECT(mr));
object_ref(mr->owner);
}
}
@@ -1816,6 +1820,7 @@ void memory_region_unref(MemoryRegion *mr)
{
if (mr && mr->owner) {
object_unref(mr->owner);
+object_unref(OBJECT(mr));
}
}
--
2.34.1
[QEMU PATCH v5 05/13] virtio-gpu: Configure context init for virglrenderer
Configure context init feature flag for virglrenderer.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
V4 -> V5:
- Inverted patch 5 and 6 because we should configure
HAVE_VIRGL_CONTEXT_INIT firstly. (Philippe)
meson.build | 4
1 file changed, 4 insertions(+)
diff --git a/meson.build b/meson.build
index 98e68ef0b1..ff20d3c249 100644
--- a/meson.build
+++ b/meson.build
@@ -1068,6 +1068,10 @@ if not get_option('virglrenderer').auto() or have_system
or have_vhost_user_gpu
prefix: '#include ',
dependencies: virgl))
endif
+ config_host_data.set('HAVE_VIRGL_CONTEXT_INIT',
+
cc.has_function('virgl_renderer_context_create_with_flags',
+ prefix: '#include ',
+ dependencies: virgl))
endif
blkio = not_found
if not get_option('blkio').auto() or have_block
--
2.34.1
[QEMU PATCH v5 06/13] virtio-gpu: Support context init feature with virglrenderer
Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
feature flags.
We would like to enable the feature with virglrenderer, so add to create
virgl renderer context with flags using context_id when valid.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
V4 -> V5:
- Inverted patch 5 and 6 because we should configure
HAVE_VIRGL_CONTEXT_INIT firstly. (Philippe)
hw/display/virtio-gpu-virgl.c | 13 +++--
hw/display/virtio-gpu.c | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 8bb7a2c21f..312953ec16 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
cc.debug_name);
-virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
- cc.debug_name);
+if (cc.context_init) {
+#ifdef HAVE_VIRGL_CONTEXT_INIT
+virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
+ cc.context_init,
+ cc.nlen,
+ cc.debug_name);
+return;
+#endif
+}
+
+virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
}
static void virgl_cmd_context_destroy(VirtIOGPU *g,
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 3e658f1fef..a66cbd9930 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1506,6 +1506,8 @@ static Property virtio_gpu_properties[] = {
DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
+DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
+VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, false),
DEFINE_PROP_END_OF_LIST(),
};
--
2.34.1
[QEMU PATCH v5 04/13] virtio-gpu: blob prep
From: Antonio Caggiano
This adds preparatory functions needed to:
- decode blob cmds
- tracking iovecs
Signed-off-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
Signed-off-by: Gurchetan Singh
Tested-by: Alyssa Ross
Tested-by: Emmanouil Pitsidianakis
Tested-by: Akihiko Odaki
Tested-by: Huang Rui
Acked-by: Huang Rui
Reviewed-by: Emmanouil Pitsidianakis
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/display/virtio-gpu.c | 10 +++---
include/hw/virtio/virtio-gpu-bswap.h | 15 +++
include/hw/virtio/virtio-gpu.h | 5 +
3 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 48ef0d9fad..3e658f1fef 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -33,15 +33,11 @@
#define VIRTIO_GPU_VM_VERSION 1
-static struct virtio_gpu_simple_resource*
-virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id);
static struct virtio_gpu_simple_resource *
virtio_gpu_find_check_resource(VirtIOGPU *g, uint32_t resource_id,
bool require_backing,
const char *caller, uint32_t *error);
-static void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
- struct virtio_gpu_simple_resource *res);
static void virtio_gpu_reset_bh(void *opaque);
void virtio_gpu_update_cursor_data(VirtIOGPU *g,
@@ -116,7 +112,7 @@ static void update_cursor(VirtIOGPU *g, struct
virtio_gpu_update_cursor *cursor)
cursor->resource_id ? 1 : 0);
}
-static struct virtio_gpu_simple_resource *
+struct virtio_gpu_simple_resource *
virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id)
{
struct virtio_gpu_simple_resource *res;
@@ -904,8 +900,8 @@ void virtio_gpu_cleanup_mapping_iov(VirtIOGPU *g,
g_free(iov);
}
-static void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
- struct virtio_gpu_simple_resource *res)
+void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
+struct virtio_gpu_simple_resource *res)
{
virtio_gpu_cleanup_mapping_iov(g, res->iov, res->iov_cnt);
res->iov = NULL;
diff --git a/include/hw/virtio/virtio-gpu-bswap.h
b/include/hw/virtio/virtio-gpu-bswap.h
index 637a0585d0..dd1975e2d4 100644
--- a/include/hw/virtio/virtio-gpu-bswap.h
+++ b/include/hw/virtio/virtio-gpu-bswap.h
@@ -70,6 +70,21 @@ virtio_gpu_create_blob_bswap(struct
virtio_gpu_resource_create_blob *cblob)
le64_to_cpus(>size);
}
+static inline void
+virtio_gpu_map_blob_bswap(struct virtio_gpu_resource_map_blob *mblob)
+{
+virtio_gpu_ctrl_hdr_bswap(>hdr);
+le32_to_cpus(>resource_id);
+le64_to_cpus(>offset);
+}
+
+static inline void
+virtio_gpu_unmap_blob_bswap(struct virtio_gpu_resource_unmap_blob *ublob)
+{
+virtio_gpu_ctrl_hdr_bswap(>hdr);
+le32_to_cpus(>resource_id);
+}
+
static inline void
virtio_gpu_scanout_blob_bswap(struct virtio_gpu_set_scanout_blob *ssb)
{
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index de4f624e94..55973e112f 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -257,6 +257,9 @@ void virtio_gpu_base_fill_display_info(VirtIOGPUBase *g,
void virtio_gpu_base_generate_edid(VirtIOGPUBase *g, int scanout,
struct virtio_gpu_resp_edid *edid);
/* virtio-gpu.c */
+struct virtio_gpu_simple_resource *
+virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id);
+
void virtio_gpu_ctrl_response(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd,
struct virtio_gpu_ctrl_hdr *resp,
@@ -275,6 +278,8 @@ int virtio_gpu_create_mapping_iov(VirtIOGPU *g,
uint32_t *niov);
void virtio_gpu_cleanup_mapping_iov(VirtIOGPU *g,
struct iovec *iov, uint32_t count);
+void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
+struct virtio_gpu_simple_resource *res);
void virtio_gpu_process_cmdq(VirtIOGPU *g);
void virtio_gpu_device_realize(DeviceState *qdev, Error **errp);
void virtio_gpu_reset(VirtIODevice *vdev);
--
2.34.1
[QEMU PATCH v5 02/13] virtio-gpu: CONTEXT_INIT feature
From: Antonio Caggiano
The feature can be enabled when a backend wants it.
Signed-off-by: Antonio Caggiano
Signed-off-by: Gurchetan Singh
Tested-by: Alyssa Ross
Tested-by: Akihiko Odaki
Tested-by: Huang Rui
Acked-by: Huang Rui
Reviewed-by: Marc-André Lureau
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/display/virtio-gpu-base.c | 3 +++
include/hw/virtio/virtio-gpu.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index ca1fb7b16f..4f2b0ba1f3 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -232,6 +232,9 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
if (virtio_gpu_blob_enabled(g->conf)) {
features |= (1 << VIRTIO_GPU_F_RESOURCE_BLOB);
}
+if (virtio_gpu_context_init_enabled(g->conf)) {
+features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
+}
return features;
}
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 390c4642b8..8377c365ef 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -93,6 +93,7 @@ enum virtio_gpu_base_conf_flags {
VIRTIO_GPU_FLAG_EDID_ENABLED,
VIRTIO_GPU_FLAG_DMABUF_ENABLED,
VIRTIO_GPU_FLAG_BLOB_ENABLED,
+VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED,
};
#define virtio_gpu_virgl_enabled(_cfg) \
@@ -105,6 +106,8 @@ enum virtio_gpu_base_conf_flags {
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_DMABUF_ENABLED))
#define virtio_gpu_blob_enabled(_cfg) \
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_BLOB_ENABLED))
+#define virtio_gpu_context_init_enabled(_cfg) \
+(_cfg.flags & (1 << VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED))
struct virtio_gpu_base_conf {
uint32_t max_outputs;
--
2.34.1
[QEMU PATCH v5 03/13] virtio-gpu: hostmem
From: Gerd Hoffmann
Use VIRTIO_GPU_SHM_ID_HOST_VISIBLE as id for virtio-gpu.
Signed-off-by: Antonio Caggiano
Tested-by: Alyssa Ross
Tested-by: Akihiko Odaki
Tested-by: Huang Rui
Acked-by: Huang Rui
Acked-by: Michael S. Tsirkin
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/display/virtio-gpu-pci.c| 14 ++
hw/display/virtio-gpu.c| 1 +
hw/display/virtio-vga.c| 33 -
include/hw/virtio/virtio-gpu.h | 5 +
4 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/hw/display/virtio-gpu-pci.c b/hw/display/virtio-gpu-pci.c
index 93f214ff58..da6a99f038 100644
--- a/hw/display/virtio-gpu-pci.c
+++ b/hw/display/virtio-gpu-pci.c
@@ -33,6 +33,20 @@ static void virtio_gpu_pci_base_realize(VirtIOPCIProxy
*vpci_dev, Error **errp)
DeviceState *vdev = DEVICE(g);
int i;
+if (virtio_gpu_hostmem_enabled(g->conf)) {
+vpci_dev->msix_bar_idx = 1;
+vpci_dev->modern_mem_bar_idx = 2;
+memory_region_init(>hostmem, OBJECT(g), "virtio-gpu-hostmem",
+ g->conf.hostmem);
+pci_register_bar(_dev->pci_dev, 4,
+ PCI_BASE_ADDRESS_SPACE_MEMORY |
+ PCI_BASE_ADDRESS_MEM_PREFETCH |
+ PCI_BASE_ADDRESS_MEM_TYPE_64,
+ >hostmem);
+virtio_pci_add_shm_cap(vpci_dev, 4, 0, g->conf.hostmem,
+ VIRTIO_GPU_SHM_ID_HOST_VISIBLE);
+}
+
virtio_pci_force_virtio_1(vpci_dev);
if (!qdev_realize(vdev, BUS(_dev->bus), errp)) {
return;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index bbd5c6561a..48ef0d9fad 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1509,6 +1509,7 @@ static Property virtio_gpu_properties[] = {
256 * MiB),
DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
+DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
index e6fb0aa876..c8552ff760 100644
--- a/hw/display/virtio-vga.c
+++ b/hw/display/virtio-vga.c
@@ -115,17 +115,32 @@ static void virtio_vga_base_realize(VirtIOPCIProxy
*vpci_dev, Error **errp)
pci_register_bar(_dev->pci_dev, 0,
PCI_BASE_ADDRESS_MEM_PREFETCH, >vram);
-/*
- * Configure virtio bar and regions
- *
- * We use bar #2 for the mmio regions, to be compatible with stdvga.
- * virtio regions are moved to the end of bar #2, to make room for
- * the stdvga mmio registers at the start of bar #2.
- */
-vpci_dev->modern_mem_bar_idx = 2;
-vpci_dev->msix_bar_idx = 4;
vpci_dev->modern_io_bar_idx = 5;
+if (!virtio_gpu_hostmem_enabled(g->conf)) {
+/*
+ * Configure virtio bar and regions
+ *
+ * We use bar #2 for the mmio regions, to be compatible with stdvga.
+ * virtio regions are moved to the end of bar #2, to make room for
+ * the stdvga mmio registers at the start of bar #2.
+ */
+vpci_dev->modern_mem_bar_idx = 2;
+vpci_dev->msix_bar_idx = 4;
+} else {
+vpci_dev->msix_bar_idx = 1;
+vpci_dev->modern_mem_bar_idx = 2;
+memory_region_init(>hostmem, OBJECT(g), "virtio-gpu-hostmem",
+ g->conf.hostmem);
+pci_register_bar(_dev->pci_dev, 4,
+ PCI_BASE_ADDRESS_SPACE_MEMORY |
+ PCI_BASE_ADDRESS_MEM_PREFETCH |
+ PCI_BASE_ADDRESS_MEM_TYPE_64,
+ >hostmem);
+virtio_pci_add_shm_cap(vpci_dev, 4, 0, g->conf.hostmem,
+ VIRTIO_GPU_SHM_ID_HOST_VISIBLE);
+}
+
if (!(vpci_dev->flags & VIRTIO_PCI_FLAG_PAGE_PER_VQ)) {
/*
* with page-per-vq=off there is no padding space we can use
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 8377c365ef..de4f624e94 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -108,12 +108,15 @@ enum virtio_gpu_base_conf_flags {
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_BLOB_ENABLED))
#define virtio_gpu_context_init_enabled(_cfg) \
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED))
+#define virtio_gpu_hostmem_enabled(_cfg) \
+(_cfg.hostmem > 0)
struct virtio_gpu_base_conf {
uint32_t max_outputs;
uint32_t flags;
uint32_t xres;
uint32_t yres;
+uint64_t hostmem;
};
struct vir
[QEMU PATCH v5 01/13] virtio: Add shared memory capability
From: "Dr. David Alan Gilbert"
Define a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG' to allow
defining shared memory regions with sizes and offsets of 2^32 and more.
Multiple instances of the capability are allowed and distinguished
by a device-specific 'id'.
Signed-off-by: Dr. David Alan Gilbert
Signed-off-by: Antonio Caggiano
Signed-off-by: Gurchetan Singh
Tested-by: Alyssa Ross
Tested-by: Huang Rui
Tested-by: Akihiko Odaki
Acked-by: Huang Rui
Reviewed-by: Gurchetan Singh
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/virtio/virtio-pci.c | 18 ++
include/hw/virtio/virtio-pci.h | 4
2 files changed, 22 insertions(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index edbc0daa18..da8c9ea12d 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1435,6 +1435,24 @@ static int virtio_pci_add_mem_cap(VirtIOPCIProxy *proxy,
return offset;
}
+int virtio_pci_add_shm_cap(VirtIOPCIProxy *proxy,
+ uint8_t bar, uint64_t offset, uint64_t length,
+ uint8_t id)
+{
+struct virtio_pci_cap64 cap = {
+.cap.cap_len = sizeof cap,
+.cap.cfg_type = VIRTIO_PCI_CAP_SHARED_MEMORY_CFG,
+};
+
+cap.cap.bar = bar;
+cap.cap.length = cpu_to_le32(length);
+cap.length_hi = cpu_to_le32(length >> 32);
+cap.cap.offset = cpu_to_le32(offset);
+cap.offset_hi = cpu_to_le32(offset >> 32);
+cap.cap.id = id;
+return virtio_pci_add_mem_cap(proxy, );
+}
+
static uint64_t virtio_pci_common_read(void *opaque, hwaddr addr,
unsigned size)
{
diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
index ab2051b64b..5a3f182f99 100644
--- a/include/hw/virtio/virtio-pci.h
+++ b/include/hw/virtio/virtio-pci.h
@@ -264,4 +264,8 @@ unsigned virtio_pci_optimal_num_queues(unsigned
fixed_queues);
void virtio_pci_set_guest_notifier_fd_handler(VirtIODevice *vdev, VirtQueue
*vq,
int n, bool assign,
bool with_irqfd);
+
+int virtio_pci_add_shm_cap(VirtIOPCIProxy *proxy, uint8_t bar, uint64_t offset,
+ uint64_t length, uint8_t id);
+
#endif
--
2.34.1
Re: [QEMU PATCH v4 12/13] virtio-gpu: Initialize Venus
On Thu, Aug 31, 2023 at 11:51:50PM +0800, Dmitry Osipenko wrote:
> On 8/31/23 13:40, Antonio Caggiano wrote:
> > Hi Huang,
> >
> > Thank you for pushing this forward!
> >
> > On 31/08/2023 11:32, Huang Rui wrote:
> >> From: Antonio Caggiano
> >>
> >> Request Venus when initializing VirGL.
> >>
> >> Signed-off-by: Antonio Caggiano
> >> Signed-off-by: Huang Rui
> >> ---
> >>
> >> v1->v2:
> >> - Rebase to latest version
> >>
> >> hw/display/virtio-gpu-virgl.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/hw/display/virtio-gpu-virgl.c
> >> b/hw/display/virtio-gpu-virgl.c
> >> index 83cd8c8fd0..c5a62665bd 100644
> >> --- a/hw/display/virtio-gpu-virgl.c
> >> +++ b/hw/display/virtio-gpu-virgl.c
> >> @@ -887,6 +887,8 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> >> }
> >> #endif
> >> + flags |= VIRGL_RENDERER_VENUS;
> >> +
> >
> > VIRGL_RENDERER_VENUS is a symbol only available from virglrenderer 0.9.1
> > [0] and only if VIRGL_RENDERER_UNSTABLE_APIS is defined.
> >
> > Luckily for us, VIRGL_RENDERER_UNSTABLE_APIS is defined unconditionally
> > from virglrenderer 0.9.0 [1], so we could check for that in
> > qemu/meson.build
> >
> > e.g.
> >
> >
> > if virgl.version().version_compare('>= 0.9.0')
> > message('Enabling virglrenderer unstable APIs')
> > virgl = declare_dependency(compile_args:
> > '-DVIRGL_RENDERER_UNSTABLE_APIS',
> > dependencies: virgl)
> > endif
> >
> >
> > Also, while testing this with various versions of virglrenderer, I
> > realized there are no guarantees for Venus backend to be available in
> > the linked library. Virglrenderer should be built with
> > -Dvenus_experimental=true, and if that is not the case, the following
> > virgl_renderer_init would fail for previous versions of virglrenderer or
> > in case it has not been built with venus support.
> >
> > I would suggest another approach for that which tries initializing Venus
> > only if VIRGL_RENDERER_VENUS is actually defined. Then, if it fails
> > cause virglrenderer has not been built with venus support, try again
> > falling back to virgl only.
>
> All the APIs will be stabilized with the upcoming virglrender 1.0
> release that will happen soon. There is also a venus protocol bump, qemu
> will have to bump virglrenderer's version dependency to 1.0 for venus
> and other new features.
>
Dmitry, do you know the timeline of virglrender 1.0?
Thanks,
Ray
Re: [QEMU PATCH v4 12/13] virtio-gpu: Initialize Venus
On Thu, Aug 31, 2023 at 06:40:11PM +0800, Antonio Caggiano wrote:
> Hi Huang,
>
> Thank you for pushing this forward!
>
My pleasure! :-)
> On 31/08/2023 11:32, Huang Rui wrote:
> > From: Antonio Caggiano
> >
> > Request Venus when initializing VirGL.
> >
> > Signed-off-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > v1->v2:
> > - Rebase to latest version
> >
> > hw/display/virtio-gpu-virgl.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 83cd8c8fd0..c5a62665bd 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -887,6 +887,8 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> > }
> > #endif
> >
> > +flags |= VIRGL_RENDERER_VENUS;
> > +
>
> VIRGL_RENDERER_VENUS is a symbol only available from virglrenderer 0.9.1
> [0] and only if VIRGL_RENDERER_UNSTABLE_APIS is defined.
>
> Luckily for us, VIRGL_RENDERER_UNSTABLE_APIS is defined unconditionally
> from virglrenderer 0.9.0 [1], so we could check for that in qemu/meson.build
>
> e.g.
>
>
>if virgl.version().version_compare('>= 0.9.0')
> message('Enabling virglrenderer unstable APIs')
> virgl = declare_dependency(compile_args:
> '-DVIRGL_RENDERER_UNSTABLE_APIS',
> dependencies: virgl)
>endif
>
>
> Also, while testing this with various versions of virglrenderer, I
> realized there are no guarantees for Venus backend to be available in
> the linked library. Virglrenderer should be built with
> -Dvenus_experimental=true, and if that is not the case, the following
> virgl_renderer_init would fail for previous versions of virglrenderer or
> in case it has not been built with venus support.
>
> I would suggest another approach for that which tries initializing Venus
> only if VIRGL_RENDERER_VENUS is actually defined. Then, if it fails
> cause virglrenderer has not been built with venus support, try again
> falling back to virgl only.
>
> e.g.
>
> #ifdef VIRGL_RENDERER_VENUS
> ret = virgl_renderer_init(g, VIRGL_RENDERER_VENUS, _gpu_3d_cbs);
> if (ret != 0) {
> warn_report("Failed to initialize virglrenderer with venus:
> %d", ret);
> warn_report("Falling back to virgl only");
> ret = virgl_renderer_init(g, 0, _gpu_3d_cbs);
> }
> #else
> ret = virgl_renderer_init(g, 0, _gpu_3d_cbs);
> #endif
>
Thanks a lot to explain so clearly. Yes, it's reasonable for me. I will
modify it in the next version. And agree, we should take care of different
virglrenderer versions.
Thanks,
Ray
>
> > ret = virgl_renderer_init(g, flags, _gpu_3d_cbs);
> > if (ret != 0) {
> > error_report("virgl could not be initialized: %d", ret);
>
> [0]
> https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/6c31f85330bb4c5aba8b82eba606971e598c6e25
> [1]
> https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/491afdc42a49ec6a1b8d7cbc5c97360229002d41
>
> Best regards,
> Antonio Caggiano
Re: [QEMU PATCH v4 11/13] virtio-gpu: Support Venus capset
On Thu, Aug 31, 2023 at 06:43:17PM +0800, Akihiko Odaki wrote:
> On 2023/08/31 18:32, Huang Rui wrote:
> > From: Antonio Caggiano
> >
> > Add support for the Venus capset, which enables Vulkan support through
> > the Venus Vulkan driver for virtio-gpu.
> >
> > Signed-off-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> > hw/display/virtio-gpu-virgl.c | 21 +
> > include/standard-headers/linux/virtio_gpu.h | 2 ++
> > 2 files changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 1a996a08fc..83cd8c8fd0 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -437,6 +437,11 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
> > virgl_renderer_get_cap_set(resp.capset_id,
> > _max_version,
> > _max_size);
> > +} else if (info.capset_index == 2) {
> > +resp.capset_id = VIRTIO_GPU_CAPSET_VENUS;
> > +virgl_renderer_get_cap_set(resp.capset_id,
> > + _max_version,
> > + _max_size);
> > } else {
> > resp.capset_max_version = 0;
> > resp.capset_max_size = 0;
> > @@ -901,10 +906,18 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> >
> > int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
> > {
> > -uint32_t capset2_max_ver, capset2_max_size;
> > +uint32_t capset2_max_ver, capset2_max_size, num_capsets;
> > +num_capsets = 1;
> > +
> > virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
> > - _max_ver,
> > - _max_size);
> > + _max_ver,
> > + _max_size);
> > +num_capsets += capset2_max_ver ? 1 : 0;
> > +
> > +virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
> > + _max_ver,
> > + _max_size);
> > +num_capsets += capset2_max_size ? 1 : 0;
> >
> > -return capset2_max_ver ? 2 : 1;
> > +return num_capsets;
> > }
> > diff --git a/include/standard-headers/linux/virtio_gpu.h
> > b/include/standard-headers/linux/virtio_gpu.h
> > index 2da48d3d4c..2db643ed8f 100644
> > --- a/include/standard-headers/linux/virtio_gpu.h
> > +++ b/include/standard-headers/linux/virtio_gpu.h
> > @@ -309,6 +309,8 @@ struct virtio_gpu_cmd_submit {
> >
> > #define VIRTIO_GPU_CAPSET_VIRGL 1
> > #define VIRTIO_GPU_CAPSET_VIRGL2 2
> > +/* 3 is reserved for gfxstream */
> > +#define VIRTIO_GPU_CAPSET_VENUS 4
>
> This file is synced with scripts/update-linux-headers.sh and should not
> be modified.
Should I add marco in kernel include/uapi/linux/virtio_gpu.h?
They are used at VIRGL_RENDERER_UNSTABLE_APIS in virglrender.
enum virgl_renderer_capset {
VIRGL_RENDERER_CAPSET_VIRGL = 1,
VIRGL_RENDERER_CAPSET_VIRGL2 = 2,
/* 3 is reserved for gfxstream */
VIRGL_RENDERER_CAPSET_VENUS = 4,
/* 5 is reserved for cross-domain */
VIRGL_RENDERER_CAPSET_DRM = 6,
};
Thanks,
Ray
>
> >
> > /* VIRTIO_GPU_CMD_GET_CAPSET_INFO */
> > struct virtio_gpu_get_capset_info {
Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID
On Thu, Aug 31, 2023 at 06:36:57PM +0800, Akihiko Odaki wrote:
> On 2023/08/31 18:32, Huang Rui wrote:
> > From: Antonio Caggiano
> >
> > Enable resource UUID feature and implement command resource assign UUID.
> > This is done by introducing a hash table to map resource IDs to their
> > UUIDs.
>
> The hash table does not seem to be stored during migration.
May I know whether you point g->resource_uuids table data in VirtIOGPU
device should be stored in virtio_gpu_save() and resumed in
virtio_gpu_load() for virtio migration?
>
> >
> > Signed-off-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > v1->v2:
> > - Separate declarations from code.
> >
> > hw/display/trace-events| 1 +
> > hw/display/virtio-gpu-base.c | 2 ++
> > hw/display/virtio-gpu-virgl.c | 21 +
> > hw/display/virtio-gpu.c| 41 ++
> > include/hw/virtio/virtio-gpu.h | 4
> > 5 files changed, 69 insertions(+)
> >
> > diff --git a/hw/display/trace-events b/hw/display/trace-events
> > index 2336a0ca15..54d6894c59 100644
> > --- a/hw/display/trace-events
> > +++ b/hw/display/trace-events
> > @@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t
> > size) "res 0x%x, size %" P
> > virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
> > +virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
> > virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
> > diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
> > index 4f2b0ba1f3..f44388715c 100644
> > --- a/hw/display/virtio-gpu-base.c
> > +++ b/hw/display/virtio-gpu-base.c
> > @@ -236,6 +236,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev,
> > uint64_t features,
> > features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
> > }
> >
> > +features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
> > +
> > return features;
> > }
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index 17b634d4ee..1a996a08fc 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -36,6 +36,7 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
> > {
> > struct virtio_gpu_resource_create_2d c2d;
> > struct virgl_renderer_resource_create_args args;
> > +struct virtio_gpu_simple_resource *res;
> >
> > VIRTIO_GPU_FILL_CMD(c2d);
> > trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
> > @@ -53,6 +54,14 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
> > args.nr_samples = 0;
> > args.flags = VIRTIO_GPU_RESOURCE_FLAG_Y_0_TOP;
> > virgl_renderer_resource_create(, NULL, 0);
> > +
> > +res = g_new0(struct virtio_gpu_simple_resource, 1);
> > +if (!res) {
> > +cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
> > +return;
>
> virglrenderer thinks the resource is alive in such a situation.
Yes, so we can move the resource allocation in front of below virglrenderer
resource creation.
virgl_renderer_resource_create(, NULL, 0);
>
> > +}
> > +res->resource_id = c2d.resource_id;
> > +QTAILQ_INSERT_HEAD(>reslist, res, next);
> > }
> >
> > static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> > @@ -60,6 +69,7 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> > {
> > struct virtio_gpu_resource_create_3d c3d;
> > struct virgl_renderer_resource_create_args args;
> > +struct virtio_gpu_simple_resource *res;
> >
> > VIRTIO_GPU_FILL_CMD(c3d);
> > trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
> > @@ -77,6 +87,14 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> > args.nr_samples = c3d.nr_samples;
> > args.flags = c3d.flags;
> > virgl_renderer_resource_create(, NULL, 0);
> > +
> > +res = g_new0(struct virtio_gpu_simple_resource, 1);
> > +if (!res) {
> > +cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
> > +return;
> > +}
> > +res->reso
Re: [QEMU PATCH v4 09/13] virtio-gpu: Handle resource blob commands
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 > >>>>> > >>>>> 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 > >>>>> Signed-off-by: Dmitry Osipenko > >>>>> Signed-off-by: Xenia Ragiadakou > >>>>> Signed-off-by: Huang Rui > >>>>> --- > >>>>> > >>>>> 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(>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(, NULL, 0); > >>
Re: [QEMU PATCH v4 09/13] virtio-gpu: Handle resource blob commands
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
> >>>
> >>> 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
> >>> Signed-off-by: Dmitry Osipenko
> >>> Signed-off-by: Xenia Ragiadakou
> >>> Signed-off-by: Huang Rui
> >>> ---
> >>>
> >>> 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(>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(, NULL, 0);
> >>>}
> >>>
> >>> +static void virgl_resource_destroy(VirtIOGPU *g,
> >>> + struct virtio_gpu_simple_resource
> >>> *res)
> >>> +{
> >>> +if (!res)
> >>> +return;
> >>> +
> >>> +QTAILQ_REMOVE(>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;
Re: [QEMU PATCH v4 07/13] softmmu/memory: enable automatic deallocation of memory regions
On Tue, Sep 05, 2023 at 05:17:32PM +0800, Akihiko Odaki wrote:
> On 2023/09/05 18:07, Huang Rui wrote:
> > On Thu, Aug 31, 2023 at 06:10:08PM +0800, Akihiko Odaki wrote:
> >> On 2023/08/31 18:32, Huang Rui wrote:
> >>> From: Xenia Ragiadakou
> >>>
> >>> When the memory region has a different life-cycle from that of her parent,
> >>> could be automatically released, once has been unparent and once all of
> >>> her
> >>> references have gone away, via the object's free callback.
> >>>
> >>> However, currently, references to the memory region are held by its owner
> >>> without first incrementing the memory region object's reference count.
> >>> As a result, the automatic deallocation of the object, not taking into
> >>> account those references, results in use-after-free memory corruption.
> >>>
> >>> This patch increases the reference count of the memory region object on
> >>> each memory_region_ref() and decreases it on each memory_region_unref().
> >>>
> >>> Signed-off-by: Xenia Ragiadakou
> >>> Signed-off-by: Huang Rui
> >>> ---
> >>>
> >>> New patch
> >>>
> >>>softmmu/memory.c | 19 +--
> >>>1 file changed, 17 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/softmmu/memory.c b/softmmu/memory.c
> >>> index 7d9494ce70..0fdd5eebf9 100644
> >>> --- a/softmmu/memory.c
> >>> +++ b/softmmu/memory.c
> >>> @@ -1797,6 +1797,15 @@ Object *memory_region_owner(MemoryRegion *mr)
> >>>
> >>>void memory_region_ref(MemoryRegion *mr)
> >>>{
> >>> +if (!mr) {
> >>> +return;
> >>> +}
> >>> +
> >>> +/* Obtain a reference to prevent the memory region object
> >>> + * from being released under our feet.
> >>> + */
> >>> +object_ref(OBJECT(mr));
> >>> +
> >>>/* MMIO callbacks most likely will access data that belongs
> >>> * to the owner, hence the need to ref/unref the owner whenever
> >>> * the memory region is in use.
> >>> @@ -1807,16 +1816,22 @@ void memory_region_ref(MemoryRegion *mr)
> >>> * Memory regions without an owner are supposed to never go away;
> >>> * we do not ref/unref them because it slows down DMA sensibly.
> >>> */
> >>
> >> The collapsed comment says:
> >> > The memory region is a child of its owner. As long as the
> >> > owner doesn't call unparent itself on the memory region,
> >> > ref-ing the owner will also keep the memory region alive.
> >> > Memory regions without an owner are supposed to never go away;
> >> > we do not ref/unref them because it slows down DMA sensibly.
> >>
> >> It contradicts with this patch.
> >
> > The reason that we modify it is because we would like to address the memory
> > leak issue in the original codes. Please see below, we find the memory
> > region will be crashed once we free(unref) the simple resource, because the
> > region will be freed in object_finalize() after unparent and the ref count
> > is to 0. Then the VM will be crashed with this.
> >
> > In virgl_cmd_resource_map_blob():
> > memory_region_init_ram_device_ptr(res->region, OBJECT(g), NULL, size,
> > data);
> > OBJECT(res->region)->free = g_free;
> > memory_region_add_subregion(>hostmem, mblob.offset, res->region);
> > memory_region_set_enabled(res->region, true);
> >
> > In virtio_gpu_virgl_resource_unmap():
> > memory_region_set_enabled(res->region, false);
> > memory_region_del_subregion(>hostmem, res->region);
> > object_unparent(OBJECT(res->region));
> > res->region = NULL;
> >
> > I spent a bit more time to understand your point, do you want me to update
> > corresponding comments or you have some concern about this change?
>
> As the comment says ref-ing memory regions without an owner will slow
> down DMA, you should avoid that. More concretely, you should check
> mr->owner before doing object_ref(OBJECT(mr)).
>
I get it, thanks to point this exactly. Will update it in V5.
Thanks,
Ray
Re: [QEMU PATCH v4 07/13] softmmu/memory: enable automatic deallocation of memory regions
On Thu, Aug 31, 2023 at 06:10:08PM +0800, Akihiko Odaki wrote:
> On 2023/08/31 18:32, Huang Rui wrote:
> > From: Xenia Ragiadakou
> >
> > When the memory region has a different life-cycle from that of her parent,
> > could be automatically released, once has been unparent and once all of her
> > references have gone away, via the object's free callback.
> >
> > However, currently, references to the memory region are held by its owner
> > without first incrementing the memory region object's reference count.
> > As a result, the automatic deallocation of the object, not taking into
> > account those references, results in use-after-free memory corruption.
> >
> > This patch increases the reference count of the memory region object on
> > each memory_region_ref() and decreases it on each memory_region_unref().
> >
> > Signed-off-by: Xenia Ragiadakou
> > Signed-off-by: Huang Rui
> > ---
> >
> > New patch
> >
> > softmmu/memory.c | 19 +--
> > 1 file changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/softmmu/memory.c b/softmmu/memory.c
> > index 7d9494ce70..0fdd5eebf9 100644
> > --- a/softmmu/memory.c
> > +++ b/softmmu/memory.c
> > @@ -1797,6 +1797,15 @@ Object *memory_region_owner(MemoryRegion *mr)
> >
> > void memory_region_ref(MemoryRegion *mr)
> > {
> > +if (!mr) {
> > +return;
> > +}
> > +
> > +/* Obtain a reference to prevent the memory region object
> > + * from being released under our feet.
> > + */
> > +object_ref(OBJECT(mr));
> > +
> > /* MMIO callbacks most likely will access data that belongs
> >* to the owner, hence the need to ref/unref the owner whenever
> >* the memory region is in use.
> > @@ -1807,16 +1816,22 @@ void memory_region_ref(MemoryRegion *mr)
> >* Memory regions without an owner are supposed to never go away;
> >* we do not ref/unref them because it slows down DMA sensibly.
> >*/
>
> The collapsed comment says:
> > The memory region is a child of its owner. As long as the
> > owner doesn't call unparent itself on the memory region,
> > ref-ing the owner will also keep the memory region alive.
> > Memory regions without an owner are supposed to never go away;
> > we do not ref/unref them because it slows down DMA sensibly.
>
> It contradicts with this patch.
The reason that we modify it is because we would like to address the memory
leak issue in the original codes. Please see below, we find the memory
region will be crashed once we free(unref) the simple resource, because the
region will be freed in object_finalize() after unparent and the ref count
is to 0. Then the VM will be crashed with this.
In virgl_cmd_resource_map_blob():
memory_region_init_ram_device_ptr(res->region, OBJECT(g), NULL, size, data);
OBJECT(res->region)->free = g_free;
memory_region_add_subregion(>hostmem, mblob.offset, res->region);
memory_region_set_enabled(res->region, true);
In virtio_gpu_virgl_resource_unmap():
memory_region_set_enabled(res->region, false);
memory_region_del_subregion(>hostmem, res->region);
object_unparent(OBJECT(res->region));
res->region = NULL;
I spent a bit more time to understand your point, do you want me to update
corresponding comments or you have some concern about this change?
Thanks,
Ray
>
> > -if (mr && mr->owner) {
> > +if (mr->owner) {
> > object_ref(mr->owner);
> > }
> > }
> >
> > void memory_region_unref(MemoryRegion *mr)
> > {
> > -if (mr && mr->owner) {
> > +if (!mr) {
> > +return;
> > +}
> > +
> > +if (mr->owner) {
> > object_unref(mr->owner);
> > }
> > +
> > +object_unref(OBJECT(mr));
> > }
> >
> > uint64_t memory_region_size(MemoryRegion *mr)
Re: [QEMU PATCH v4 09/13] virtio-gpu: Handle resource blob commands
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
> >
> > 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
> > Signed-off-by: Dmitry Osipenko
> > Signed-off-by: Xenia Ragiadakou
> > Signed-off-by: Huang Rui
> > ---
> >
> > 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(>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(, NULL, 0);
> > }
> >
> > +static void virgl_resource_destroy(VirtIOGPU *g,
> > + struct virtio_gpu_simple_resource *res)
> > +{
> > +if (!res)
> > +return;
> > +
> > +QTAILQ_REMOVE(>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,
> > _iovs,
> > _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);
> > +
&
Re: [QEMU PATCH v4 06/13] virtio-gpu: Configure context init for virglrenderer
On Thu, Aug 31, 2023 at 05:39:38PM +0800, Philippe Mathieu-Daudé wrote:
> On 31/8/23 11:32, Huang Rui wrote:
> > Configure context init feature flag for virglrenderer.
> >
> > Originally-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > New patch, result of splitting
> > [RFC QEMU PATCH 04/18] virtio-gpu: CONTEXT_INIT feature
> >
> > meson.build | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/meson.build b/meson.build
> > index 98e68ef0b1..ff20d3c249 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1068,6 +1068,10 @@ if not get_option('virglrenderer').auto() or
> > have_system or have_vhost_user_gpu
> > prefix: '#include
> > ',
> > dependencies: virgl))
> > endif
> > + config_host_data.set('HAVE_VIRGL_CONTEXT_INIT',
> > +
> > cc.has_function('virgl_renderer_context_create_with_flags',
> > + prefix: '#include
> > ',
> > + dependencies: virgl))
>
> Shouldn't this be inverted with previous patch?
>
Yes, this should be patch 3 because we should configure
HAVE_VIRGL_CONTEXT_INIT firstly. I will update it in next version.
Thanks
Ray
[QEMU PATCH v4 11/13] virtio-gpu: Support Venus capset
From: Antonio Caggiano
Add support for the Venus capset, which enables Vulkan support through
the Venus Vulkan driver for virtio-gpu.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
hw/display/virtio-gpu-virgl.c | 21 +
include/standard-headers/linux/virtio_gpu.h | 2 ++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 1a996a08fc..83cd8c8fd0 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -437,6 +437,11 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
virgl_renderer_get_cap_set(resp.capset_id,
_max_version,
_max_size);
+} else if (info.capset_index == 2) {
+resp.capset_id = VIRTIO_GPU_CAPSET_VENUS;
+virgl_renderer_get_cap_set(resp.capset_id,
+ _max_version,
+ _max_size);
} else {
resp.capset_max_version = 0;
resp.capset_max_size = 0;
@@ -901,10 +906,18 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
{
-uint32_t capset2_max_ver, capset2_max_size;
+uint32_t capset2_max_ver, capset2_max_size, num_capsets;
+num_capsets = 1;
+
virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
- _max_ver,
- _max_size);
+ _max_ver,
+ _max_size);
+num_capsets += capset2_max_ver ? 1 : 0;
+
+virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
+ _max_ver,
+ _max_size);
+num_capsets += capset2_max_size ? 1 : 0;
-return capset2_max_ver ? 2 : 1;
+return num_capsets;
}
diff --git a/include/standard-headers/linux/virtio_gpu.h
b/include/standard-headers/linux/virtio_gpu.h
index 2da48d3d4c..2db643ed8f 100644
--- a/include/standard-headers/linux/virtio_gpu.h
+++ b/include/standard-headers/linux/virtio_gpu.h
@@ -309,6 +309,8 @@ struct virtio_gpu_cmd_submit {
#define VIRTIO_GPU_CAPSET_VIRGL 1
#define VIRTIO_GPU_CAPSET_VIRGL2 2
+/* 3 is reserved for gfxstream */
+#define VIRTIO_GPU_CAPSET_VENUS 4
/* VIRTIO_GPU_CMD_GET_CAPSET_INFO */
struct virtio_gpu_get_capset_info {
--
2.34.1
[QEMU PATCH v4 08/13] virtio-gpu: Don't require udmabuf when blobs and virgl are enabled
From: Dmitry Osipenko
The udmabuf usage is mandatory when virgl is disabled and blobs feature
enabled in the Qemu machine configuration. If virgl and blobs are enabled,
then udmabuf requirement is optional. Since udmabuf isn't widely supported
by a popular Linux distros today, let's relax the udmabuf requirement for
blobs=on,virgl=on. Now, a full-featured virtio-gpu acceleration is
available to Qemu users without a need to have udmabuf available in the
system.
Reviewed-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
Signed-off-by: Huang Rui
---
New patch
hw/display/virtio-gpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index a66cbd9930..5b7a7eab4f 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1361,7 +1361,8 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error
**errp)
VirtIOGPU *g = VIRTIO_GPU(qdev);
if (virtio_gpu_blob_enabled(g->parent_obj.conf)) {
-if (!virtio_gpu_have_udmabuf()) {
+if (!virtio_gpu_virgl_enabled(g->parent_obj.conf) &&
+!virtio_gpu_have_udmabuf()) {
error_setg(errp, "cannot enable blob resources without udmabuf");
return;
}
--
2.34.1
[QEMU PATCH v4 12/13] virtio-gpu: Initialize Venus
From: Antonio Caggiano
Request Venus when initializing VirGL.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
v1->v2:
- Rebase to latest version
hw/display/virtio-gpu-virgl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 83cd8c8fd0..c5a62665bd 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -887,6 +887,8 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
}
#endif
+flags |= VIRGL_RENDERER_VENUS;
+
ret = virgl_renderer_init(g, flags, _gpu_3d_cbs);
if (ret != 0) {
error_report("virgl could not be initialized: %d", ret);
--
2.34.1
[QEMU PATCH v4 01/13] virtio: Add shared memory capability
From: "Dr. David Alan Gilbert"
Define a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG' to allow
defining shared memory regions with sizes and offsets of 2^32 and more.
Multiple instances of the capability are allowed and distinguished
by a device-specific 'id'.
Signed-off-by: Dr. David Alan Gilbert
Signed-off-by: Antonio Caggiano
Signed-off-by: Gurchetan Singh
Tested-by: Alyssa Ross
Tested-by: Huang Rui
Tested-by: Akihiko Odaki
Acked-by: Huang Rui
Reviewed-by: Gurchetan Singh
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/virtio/virtio-pci.c | 18 ++
include/hw/virtio/virtio-pci.h | 4
2 files changed, 22 insertions(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index edbc0daa18..da8c9ea12d 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1435,6 +1435,24 @@ static int virtio_pci_add_mem_cap(VirtIOPCIProxy *proxy,
return offset;
}
+int virtio_pci_add_shm_cap(VirtIOPCIProxy *proxy,
+ uint8_t bar, uint64_t offset, uint64_t length,
+ uint8_t id)
+{
+struct virtio_pci_cap64 cap = {
+.cap.cap_len = sizeof cap,
+.cap.cfg_type = VIRTIO_PCI_CAP_SHARED_MEMORY_CFG,
+};
+
+cap.cap.bar = bar;
+cap.cap.length = cpu_to_le32(length);
+cap.length_hi = cpu_to_le32(length >> 32);
+cap.cap.offset = cpu_to_le32(offset);
+cap.offset_hi = cpu_to_le32(offset >> 32);
+cap.cap.id = id;
+return virtio_pci_add_mem_cap(proxy, );
+}
+
static uint64_t virtio_pci_common_read(void *opaque, hwaddr addr,
unsigned size)
{
diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
index ab2051b64b..5a3f182f99 100644
--- a/include/hw/virtio/virtio-pci.h
+++ b/include/hw/virtio/virtio-pci.h
@@ -264,4 +264,8 @@ unsigned virtio_pci_optimal_num_queues(unsigned
fixed_queues);
void virtio_pci_set_guest_notifier_fd_handler(VirtIODevice *vdev, VirtQueue
*vq,
int n, bool assign,
bool with_irqfd);
+
+int virtio_pci_add_shm_cap(VirtIOPCIProxy *proxy, uint8_t bar, uint64_t offset,
+ uint64_t length, uint8_t id);
+
#endif
--
2.34.1
[QEMU PATCH v4 10/13] virtio-gpu: Resource UUID
From: Antonio Caggiano
Enable resource UUID feature and implement command resource assign UUID.
This is done by introducing a hash table to map resource IDs to their
UUIDs.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
v1->v2:
- Separate declarations from code.
hw/display/trace-events| 1 +
hw/display/virtio-gpu-base.c | 2 ++
hw/display/virtio-gpu-virgl.c | 21 +
hw/display/virtio-gpu.c| 41 ++
include/hw/virtio/virtio-gpu.h | 4
5 files changed, 69 insertions(+)
diff --git a/hw/display/trace-events b/hw/display/trace-events
index 2336a0ca15..54d6894c59 100644
--- a/hw/display/trace-events
+++ b/hw/display/trace-events
@@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t size)
"res 0x%x, size %" P
virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
+virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index 4f2b0ba1f3..f44388715c 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -236,6 +236,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
}
+features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
+
return features;
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 17b634d4ee..1a996a08fc 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -36,6 +36,7 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_2d c2d;
struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_simple_resource *res;
VIRTIO_GPU_FILL_CMD(c2d);
trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
@@ -53,6 +54,14 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
args.nr_samples = 0;
args.flags = VIRTIO_GPU_RESOURCE_FLAG_Y_0_TOP;
virgl_renderer_resource_create(, NULL, 0);
+
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+return;
+}
+res->resource_id = c2d.resource_id;
+QTAILQ_INSERT_HEAD(>reslist, res, next);
}
static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
@@ -60,6 +69,7 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_3d c3d;
struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_simple_resource *res;
VIRTIO_GPU_FILL_CMD(c3d);
trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
@@ -77,6 +87,14 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
args.nr_samples = c3d.nr_samples;
args.flags = c3d.flags;
virgl_renderer_resource_create(, NULL, 0);
+
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+return;
+}
+res->resource_id = c3d.resource_id;
+QTAILQ_INSERT_HEAD(>reslist, res, next);
}
static void virgl_resource_destroy(VirtIOGPU *g,
@@ -682,6 +700,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
/* TODO add security */
virgl_cmd_ctx_detach_resource(g, cmd);
break;
+case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
+virtio_gpu_resource_assign_uuid(g, cmd);
+break;
case VIRTIO_GPU_CMD_GET_CAPSET_INFO:
virgl_cmd_get_capset_info(g, cmd);
break;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index cc4c1f81bb..770e4747e3 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -966,6 +966,37 @@ virtio_gpu_resource_detach_backing(VirtIOGPU *g,
virtio_gpu_cleanup_mapping(g, res);
}
+void virtio_gpu_resource_assign_uuid(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_simple_resource *res;
+struct virtio_gpu_resource_assign_uuid assign;
+struct virtio_gpu_resp_resource_uuid resp;
+QemuUUID *uuid = NULL;
+
+VIRTIO_GPU_FILL_CMD(assign);
+virtio_gpu_bswap_32(, sizeof(assign));
+trace_virtio_gpu_cmd_res_assign_uuid(assign.resource_id);
+
+res = virtio_gpu_find_check_resource(g, assign.resource_id, false,
__func__, >error);
+if (!res) {
+return;
+}
+
+memset(, 0, sizeof(resp));
+resp.hdr.type = VIRTIO_GPU_RESP_OK_RESOURCE_UUID;
+
+uuid = g_hash_table_lookup(g->resource_uuids,
GUINT_TO_POINTER(assign.resource_id))
[QEMU PATCH v4 13/13] virtio-gpu: Enable virglrenderer render server flag for venus
Venus in virglrenderer has required render server support.
Signed-off-by: Huang Rui
---
New patch
hw/display/virtio-gpu-virgl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index c5a62665bd..1ae3e458e2 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -887,7 +887,7 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
}
#endif
-flags |= VIRGL_RENDERER_VENUS;
+flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER;
ret = virgl_renderer_init(g, flags, _gpu_3d_cbs);
if (ret != 0) {
--
2.34.1
[QEMU PATCH v4 04/13] virtio-gpu: blob prep
From: Antonio Caggiano
This adds preparatory functions needed to:
- decode blob cmds
- tracking iovecs
Signed-off-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
Signed-off-by: Gurchetan Singh
Tested-by: Alyssa Ross
Tested-by: Emmanouil Pitsidianakis
Tested-by: Akihiko Odaki
Reviewed-by: Emmanouil Pitsidianakis
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/display/virtio-gpu.c | 10 +++---
include/hw/virtio/virtio-gpu-bswap.h | 15 +++
include/hw/virtio/virtio-gpu.h | 5 +
3 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 48ef0d9fad..3e658f1fef 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -33,15 +33,11 @@
#define VIRTIO_GPU_VM_VERSION 1
-static struct virtio_gpu_simple_resource*
-virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id);
static struct virtio_gpu_simple_resource *
virtio_gpu_find_check_resource(VirtIOGPU *g, uint32_t resource_id,
bool require_backing,
const char *caller, uint32_t *error);
-static void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
- struct virtio_gpu_simple_resource *res);
static void virtio_gpu_reset_bh(void *opaque);
void virtio_gpu_update_cursor_data(VirtIOGPU *g,
@@ -116,7 +112,7 @@ static void update_cursor(VirtIOGPU *g, struct
virtio_gpu_update_cursor *cursor)
cursor->resource_id ? 1 : 0);
}
-static struct virtio_gpu_simple_resource *
+struct virtio_gpu_simple_resource *
virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id)
{
struct virtio_gpu_simple_resource *res;
@@ -904,8 +900,8 @@ void virtio_gpu_cleanup_mapping_iov(VirtIOGPU *g,
g_free(iov);
}
-static void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
- struct virtio_gpu_simple_resource *res)
+void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
+struct virtio_gpu_simple_resource *res)
{
virtio_gpu_cleanup_mapping_iov(g, res->iov, res->iov_cnt);
res->iov = NULL;
diff --git a/include/hw/virtio/virtio-gpu-bswap.h
b/include/hw/virtio/virtio-gpu-bswap.h
index 637a0585d0..dd1975e2d4 100644
--- a/include/hw/virtio/virtio-gpu-bswap.h
+++ b/include/hw/virtio/virtio-gpu-bswap.h
@@ -70,6 +70,21 @@ virtio_gpu_create_blob_bswap(struct
virtio_gpu_resource_create_blob *cblob)
le64_to_cpus(>size);
}
+static inline void
+virtio_gpu_map_blob_bswap(struct virtio_gpu_resource_map_blob *mblob)
+{
+virtio_gpu_ctrl_hdr_bswap(>hdr);
+le32_to_cpus(>resource_id);
+le64_to_cpus(>offset);
+}
+
+static inline void
+virtio_gpu_unmap_blob_bswap(struct virtio_gpu_resource_unmap_blob *ublob)
+{
+virtio_gpu_ctrl_hdr_bswap(>hdr);
+le32_to_cpus(>resource_id);
+}
+
static inline void
virtio_gpu_scanout_blob_bswap(struct virtio_gpu_set_scanout_blob *ssb)
{
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index de4f624e94..55973e112f 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -257,6 +257,9 @@ void virtio_gpu_base_fill_display_info(VirtIOGPUBase *g,
void virtio_gpu_base_generate_edid(VirtIOGPUBase *g, int scanout,
struct virtio_gpu_resp_edid *edid);
/* virtio-gpu.c */
+struct virtio_gpu_simple_resource *
+virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id);
+
void virtio_gpu_ctrl_response(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd,
struct virtio_gpu_ctrl_hdr *resp,
@@ -275,6 +278,8 @@ int virtio_gpu_create_mapping_iov(VirtIOGPU *g,
uint32_t *niov);
void virtio_gpu_cleanup_mapping_iov(VirtIOGPU *g,
struct iovec *iov, uint32_t count);
+void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
+struct virtio_gpu_simple_resource *res);
void virtio_gpu_process_cmdq(VirtIOGPU *g);
void virtio_gpu_device_realize(DeviceState *qdev, Error **errp);
void virtio_gpu_reset(VirtIODevice *vdev);
--
2.34.1
[QEMU PATCH v4 09/13] virtio-gpu: Handle resource blob commands
From: Antonio Caggiano
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
Signed-off-by: Dmitry Osipenko
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
---
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(>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(, NULL, 0);
}
+static void virgl_resource_destroy(VirtIOGPU *g,
+ struct virtio_gpu_simple_resource *res)
+{
+if (!res)
+return;
+
+QTAILQ_REMOVE(>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,
_iovs,
_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();
+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
[QEMU PATCH v4 07/13] softmmu/memory: enable automatic deallocation of memory regions
From: Xenia Ragiadakou
When the memory region has a different life-cycle from that of her parent,
could be automatically released, once has been unparent and once all of her
references have gone away, via the object's free callback.
However, currently, references to the memory region are held by its owner
without first incrementing the memory region object's reference count.
As a result, the automatic deallocation of the object, not taking into
account those references, results in use-after-free memory corruption.
This patch increases the reference count of the memory region object on
each memory_region_ref() and decreases it on each memory_region_unref().
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
---
New patch
softmmu/memory.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/softmmu/memory.c b/softmmu/memory.c
index 7d9494ce70..0fdd5eebf9 100644
--- a/softmmu/memory.c
+++ b/softmmu/memory.c
@@ -1797,6 +1797,15 @@ Object *memory_region_owner(MemoryRegion *mr)
void memory_region_ref(MemoryRegion *mr)
{
+if (!mr) {
+return;
+}
+
+/* Obtain a reference to prevent the memory region object
+ * from being released under our feet.
+ */
+object_ref(OBJECT(mr));
+
/* MMIO callbacks most likely will access data that belongs
* to the owner, hence the need to ref/unref the owner whenever
* the memory region is in use.
@@ -1807,16 +1816,22 @@ void memory_region_ref(MemoryRegion *mr)
* Memory regions without an owner are supposed to never go away;
* we do not ref/unref them because it slows down DMA sensibly.
*/
-if (mr && mr->owner) {
+if (mr->owner) {
object_ref(mr->owner);
}
}
void memory_region_unref(MemoryRegion *mr)
{
-if (mr && mr->owner) {
+if (!mr) {
+return;
+}
+
+if (mr->owner) {
object_unref(mr->owner);
}
+
+object_unref(OBJECT(mr));
}
uint64_t memory_region_size(MemoryRegion *mr)
--
2.34.1
[QEMU PATCH v4 00/13] Support blob memory and venus on qemu
Hi all, Antonio Caggiano made the venus with QEMU on KVM platform last September[1]. This series are inherited from his original work to support the features of context init, hostmem, resource uuid, and blob resources for venus. At March of this year, we sent out the V1 version[2] for the review. But those series are included both xen and virtio gpu. Right now, we would like to divide into two parts, one is to continue the Antonio's work to upstream virtio-gpu support for blob memory and venus, and another is to upstream xen specific patches. This series is focusing on virtio-gpu, so we are marking as V4 version here to continue Antonio's patches[1]. And we will send xen specific patches separately, because they are hypervisor specific. Besides of QEMU, these supports also included virglrenderer[3][4] and mesa[5][6] as well. Right now, virglrenderer and mesa parts are all accepted by upstream. In this qemu version, we try to address the concerns around not proper cleanup during blob resource unmap and unref. Appreciate it if you have any commments. [1] https://lore.kernel.org/qemu-devel/20220926142422.22325-1-antonio.caggi...@collabora.com/ [2] V1: https://lore.kernel.org/qemu-devel/20230312092244.451465-1-ray.hu...@amd.com [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1068 [4] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1180 [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22108 [6] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23680 Please note the first 4 patches 1 -> 4 are inlcuded in these series because the series depends on them and not because we want them to be reviewed since they are already in the process of review through the "rutabaga_gfx + gfxstream" series. - https://lore.kernel.org/qemu-devel/20230829003629.410-1-gurchetansi...@chromium.org/ Changes from V1 to V2 (virtio gpu V4) - 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(>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 and is allocated dynamically when the blob is mapped. Also, since the pointer can be used to indicate whether the blob is mapped, the explicite 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. - Add a patch to enable automatic deallocation of memory regions to resolve use-after-free memory corruption with a reference. References Demo with Venus: - https://static.sched.com/hosted_files/xen2023/3f/xen_summit_2023_virtgpu_demo.mp4 QEMU repository: - https://gitlab.freedesktop.org/rui/qemu-xen/-/commits/upstream-for-virtio-gpu Thanks, Ray Antonio Caggiano (6): virtio-gpu: CONTEXT_INIT feature virtio-gpu: blob prep virtio-gpu: Handle resource blob commands virtio-gpu: Resource UUID virtio-gpu: Support Venus capset virtio-gpu: Initialize Venus Dmitry Osipenko (1): virtio-gpu: Don't require udmabuf when blobs and virgl are enabled Dr. David Alan Gilbert (1): virtio: Add shared memory capability Gerd Hoffmann (1): virtio-gpu: hostmem Huang Rui (3): virtio-gpu: Support context init feature with virglrenderer virtio-gpu: Configure context init for virglrenderer virtio-gpu: Enable virglrenderer render server flag for venus Xenia Ragiadakou (1): softmmu/memory: enable automatic deallocation of memory regions hw/display/trace-events | 1 + hw/display/virtio-gpu-base.c| 5 + hw/display/virtio-gpu-pci.c | 14 + hw/display/virtio-gpu-virgl.c | 270 +++- hw/display/virtio-gpu.c | 61 - hw/display/virtio-vga.c | 33 ++- hw/virtio/virtio-pci.c | 18 ++ include/hw/virtio/virtio-gpu-bswap.h| 15 ++ include/hw/virtio/virtio-gpu.h | 22 ++ include/hw/virtio/virtio-pci.h | 4 + include/standard-headers/linux/virtio_gpu.h | 2 + meson.build | 8 + softmmu/memory.c| 19 +- 13 files changed, 446 insertions(+), 26 deletions(-) -- 2.34.1
[QEMU PATCH v4 05/13] virtio-gpu: Support context init feature with virglrenderer
Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
feature flags.
We would like to enable the feature with virglrenderer, so add to create
virgl renderer context with flags using context_id when valid.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
New patch, result of splitting
[RFC QEMU PATCH 04/18] virtio-gpu: CONTEXT_INIT feature
hw/display/virtio-gpu-virgl.c | 13 +++--
hw/display/virtio-gpu.c | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 8bb7a2c21f..312953ec16 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
cc.debug_name);
-virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
- cc.debug_name);
+if (cc.context_init) {
+#ifdef HAVE_VIRGL_CONTEXT_INIT
+virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
+ cc.context_init,
+ cc.nlen,
+ cc.debug_name);
+return;
+#endif
+}
+
+virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
}
static void virgl_cmd_context_destroy(VirtIOGPU *g,
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 3e658f1fef..a66cbd9930 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1506,6 +1506,8 @@ static Property virtio_gpu_properties[] = {
DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
+DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
+VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, false),
DEFINE_PROP_END_OF_LIST(),
};
--
2.34.1
[QEMU PATCH v4 02/13] virtio-gpu: CONTEXT_INIT feature
From: Antonio Caggiano
The feature can be enabled when a backend wants it.
Signed-off-by: Antonio Caggiano
Signed-off-by: Gurchetan Singh
Tested-by: Alyssa Ross
Tested-by: Akihiko Odaki
Reviewed-by: Marc-André Lureau
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/display/virtio-gpu-base.c | 3 +++
include/hw/virtio/virtio-gpu.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index ca1fb7b16f..4f2b0ba1f3 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -232,6 +232,9 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
if (virtio_gpu_blob_enabled(g->conf)) {
features |= (1 << VIRTIO_GPU_F_RESOURCE_BLOB);
}
+if (virtio_gpu_context_init_enabled(g->conf)) {
+features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
+}
return features;
}
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 390c4642b8..8377c365ef 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -93,6 +93,7 @@ enum virtio_gpu_base_conf_flags {
VIRTIO_GPU_FLAG_EDID_ENABLED,
VIRTIO_GPU_FLAG_DMABUF_ENABLED,
VIRTIO_GPU_FLAG_BLOB_ENABLED,
+VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED,
};
#define virtio_gpu_virgl_enabled(_cfg) \
@@ -105,6 +106,8 @@ enum virtio_gpu_base_conf_flags {
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_DMABUF_ENABLED))
#define virtio_gpu_blob_enabled(_cfg) \
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_BLOB_ENABLED))
+#define virtio_gpu_context_init_enabled(_cfg) \
+(_cfg.flags & (1 << VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED))
struct virtio_gpu_base_conf {
uint32_t max_outputs;
--
2.34.1
[QEMU PATCH v4 06/13] virtio-gpu: Configure context init for virglrenderer
Configure context init feature flag for virglrenderer.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
New patch, result of splitting
[RFC QEMU PATCH 04/18] virtio-gpu: CONTEXT_INIT feature
meson.build | 4
1 file changed, 4 insertions(+)
diff --git a/meson.build b/meson.build
index 98e68ef0b1..ff20d3c249 100644
--- a/meson.build
+++ b/meson.build
@@ -1068,6 +1068,10 @@ if not get_option('virglrenderer').auto() or have_system
or have_vhost_user_gpu
prefix: '#include ',
dependencies: virgl))
endif
+ config_host_data.set('HAVE_VIRGL_CONTEXT_INIT',
+
cc.has_function('virgl_renderer_context_create_with_flags',
+ prefix: '#include ',
+ dependencies: virgl))
endif
blkio = not_found
if not get_option('blkio').auto() or have_block
--
2.34.1
[QEMU PATCH v4 03/13] virtio-gpu: hostmem
From: Gerd Hoffmann
Use VIRTIO_GPU_SHM_ID_HOST_VISIBLE as id for virtio-gpu.
Signed-off-by: Antonio Caggiano
Tested-by: Alyssa Ross
Tested-by: Akihiko Odaki
Acked-by: Michael S. Tsirkin
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/display/virtio-gpu-pci.c| 14 ++
hw/display/virtio-gpu.c| 1 +
hw/display/virtio-vga.c| 33 -
include/hw/virtio/virtio-gpu.h | 5 +
4 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/hw/display/virtio-gpu-pci.c b/hw/display/virtio-gpu-pci.c
index 93f214ff58..da6a99f038 100644
--- a/hw/display/virtio-gpu-pci.c
+++ b/hw/display/virtio-gpu-pci.c
@@ -33,6 +33,20 @@ static void virtio_gpu_pci_base_realize(VirtIOPCIProxy
*vpci_dev, Error **errp)
DeviceState *vdev = DEVICE(g);
int i;
+if (virtio_gpu_hostmem_enabled(g->conf)) {
+vpci_dev->msix_bar_idx = 1;
+vpci_dev->modern_mem_bar_idx = 2;
+memory_region_init(>hostmem, OBJECT(g), "virtio-gpu-hostmem",
+ g->conf.hostmem);
+pci_register_bar(_dev->pci_dev, 4,
+ PCI_BASE_ADDRESS_SPACE_MEMORY |
+ PCI_BASE_ADDRESS_MEM_PREFETCH |
+ PCI_BASE_ADDRESS_MEM_TYPE_64,
+ >hostmem);
+virtio_pci_add_shm_cap(vpci_dev, 4, 0, g->conf.hostmem,
+ VIRTIO_GPU_SHM_ID_HOST_VISIBLE);
+}
+
virtio_pci_force_virtio_1(vpci_dev);
if (!qdev_realize(vdev, BUS(_dev->bus), errp)) {
return;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index bbd5c6561a..48ef0d9fad 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1509,6 +1509,7 @@ static Property virtio_gpu_properties[] = {
256 * MiB),
DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
+DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
index e6fb0aa876..c8552ff760 100644
--- a/hw/display/virtio-vga.c
+++ b/hw/display/virtio-vga.c
@@ -115,17 +115,32 @@ static void virtio_vga_base_realize(VirtIOPCIProxy
*vpci_dev, Error **errp)
pci_register_bar(_dev->pci_dev, 0,
PCI_BASE_ADDRESS_MEM_PREFETCH, >vram);
-/*
- * Configure virtio bar and regions
- *
- * We use bar #2 for the mmio regions, to be compatible with stdvga.
- * virtio regions are moved to the end of bar #2, to make room for
- * the stdvga mmio registers at the start of bar #2.
- */
-vpci_dev->modern_mem_bar_idx = 2;
-vpci_dev->msix_bar_idx = 4;
vpci_dev->modern_io_bar_idx = 5;
+if (!virtio_gpu_hostmem_enabled(g->conf)) {
+/*
+ * Configure virtio bar and regions
+ *
+ * We use bar #2 for the mmio regions, to be compatible with stdvga.
+ * virtio regions are moved to the end of bar #2, to make room for
+ * the stdvga mmio registers at the start of bar #2.
+ */
+vpci_dev->modern_mem_bar_idx = 2;
+vpci_dev->msix_bar_idx = 4;
+} else {
+vpci_dev->msix_bar_idx = 1;
+vpci_dev->modern_mem_bar_idx = 2;
+memory_region_init(>hostmem, OBJECT(g), "virtio-gpu-hostmem",
+ g->conf.hostmem);
+pci_register_bar(_dev->pci_dev, 4,
+ PCI_BASE_ADDRESS_SPACE_MEMORY |
+ PCI_BASE_ADDRESS_MEM_PREFETCH |
+ PCI_BASE_ADDRESS_MEM_TYPE_64,
+ >hostmem);
+virtio_pci_add_shm_cap(vpci_dev, 4, 0, g->conf.hostmem,
+ VIRTIO_GPU_SHM_ID_HOST_VISIBLE);
+}
+
if (!(vpci_dev->flags & VIRTIO_PCI_FLAG_PAGE_PER_VQ)) {
/*
* with page-per-vq=off there is no padding space we can use
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 8377c365ef..de4f624e94 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -108,12 +108,15 @@ enum virtio_gpu_base_conf_flags {
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_BLOB_ENABLED))
#define virtio_gpu_context_init_enabled(_cfg) \
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED))
+#define virtio_gpu_hostmem_enabled(_cfg) \
+(_cfg.hostmem > 0)
struct virtio_gpu_base_conf {
uint32_t max_outputs;
uint32_t flags;
uint32_t xres;
uint32_t yres;
+uint64_t hostmem;
};
struct virtio_gpu_ctrl_command {
@@ -137,6 +140,8 @@ struct V
Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream
On Tue, Aug 29, 2023 at 08:36:20AM +0800, Gurchetan Singh wrote: > From: Gurchetan Singh > > Changes since v12: > - Added r-b tags from Antonio Caggiano and Akihiko Odaki > - Removed review version from commit messages > - I think we're good to merge since we've had multiple people test and review > this series?? > > How to build both rutabaga and gfxstream guest/host libs: > > https://crosvm.dev/book/appendix/rutabaga_gfx.html > > Branch containing this patch series: > > https://gitlab.com/gurchetansingh/qemu/-/commits/qemu-gfxstream-v13 > > Antonio Caggiano (2): > virtio-gpu: CONTEXT_INIT feature > virtio-gpu: blob prep > > Dr. David Alan Gilbert (1): > virtio: Add shared memory capability > > Gerd Hoffmann (1): > virtio-gpu: hostmem Patch 1 -> 4 are Acked-and-Tested-by: Huang Rui > > Gurchetan Singh (5): > gfxstream + rutabaga prep: added need defintions, fields, and options > gfxstream + rutabaga: add initial support for gfxstream > gfxstream + rutabaga: meson support > gfxstream + rutabaga: enable rutabaga > docs/system: add basic virtio-gpu documentation > > docs/system/device-emulation.rst |1 + > docs/system/devices/virtio-gpu.rst | 112 +++ > hw/display/meson.build | 22 + > hw/display/virtio-gpu-base.c |6 +- > hw/display/virtio-gpu-pci-rutabaga.c | 47 ++ > hw/display/virtio-gpu-pci.c | 14 + > hw/display/virtio-gpu-rutabaga.c | 1119 ++ > hw/display/virtio-gpu.c | 16 +- > hw/display/virtio-vga-rutabaga.c | 50 ++ > hw/display/virtio-vga.c | 33 +- > hw/virtio/virtio-pci.c | 18 + > include/hw/virtio/virtio-gpu-bswap.h | 15 + > include/hw/virtio/virtio-gpu.h | 41 + > include/hw/virtio/virtio-pci.h |4 + > meson.build |7 + > meson_options.txt|2 + > scripts/meson-buildoptions.sh|3 + > softmmu/qdev-monitor.c |3 + > softmmu/vl.c |1 + > 19 files changed, 1495 insertions(+), 19 deletions(-) > create mode 100644 docs/system/devices/virtio-gpu.rst > create mode 100644 hw/display/virtio-gpu-pci-rutabaga.c > create mode 100644 hw/display/virtio-gpu-rutabaga.c > create mode 100644 hw/display/virtio-vga-rutabaga.c > > -- > 2.42.0.rc2.253.gd59a3bf2b4-goog >
Re: [PATCH v4 1/9] virtio: Add shared memory capability
On Wed, Aug 09, 2023 at 10:11:00AM +0800, Gurchetan Singh wrote:
> From: "Dr. David Alan Gilbert"
>
> Define a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG' to allow
> defining shared memory regions with sizes and offsets of 2^32 and more.
> Multiple instances of the capability are allowed and distinguished
> by a device-specific 'id'.
>
> Signed-off-by: Dr. David Alan Gilbert
> Signed-off-by: Antonio Caggiano
> Reviewed-by: Gurchetan Singh
> Signed-off-by: Gurchetan Singh
> Tested-by: Alyssa Ross
> Reviewed-by: Akihiko Odaki
Acked-and-Tested-by: Huang Rui
> ---
> hw/virtio/virtio-pci.c | 18 ++
> include/hw/virtio/virtio-pci.h | 4
> 2 files changed, 22 insertions(+)
>
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index edbc0daa18..da8c9ea12d 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -1435,6 +1435,24 @@ static int virtio_pci_add_mem_cap(VirtIOPCIProxy
> *proxy,
> return offset;
> }
>
> +int virtio_pci_add_shm_cap(VirtIOPCIProxy *proxy,
> + uint8_t bar, uint64_t offset, uint64_t length,
> + uint8_t id)
> +{
> +struct virtio_pci_cap64 cap = {
> +.cap.cap_len = sizeof cap,
> +.cap.cfg_type = VIRTIO_PCI_CAP_SHARED_MEMORY_CFG,
> +};
> +
> +cap.cap.bar = bar;
> +cap.cap.length = cpu_to_le32(length);
> +cap.length_hi = cpu_to_le32(length >> 32);
> +cap.cap.offset = cpu_to_le32(offset);
> +cap.offset_hi = cpu_to_le32(offset >> 32);
> +cap.cap.id = id;
> +return virtio_pci_add_mem_cap(proxy, );
> +}
> +
> static uint64_t virtio_pci_common_read(void *opaque, hwaddr addr,
> unsigned size)
> {
> diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
> index ab2051b64b..5a3f182f99 100644
> --- a/include/hw/virtio/virtio-pci.h
> +++ b/include/hw/virtio/virtio-pci.h
> @@ -264,4 +264,8 @@ unsigned virtio_pci_optimal_num_queues(unsigned
> fixed_queues);
> void virtio_pci_set_guest_notifier_fd_handler(VirtIODevice *vdev, VirtQueue
> *vq,
>int n, bool assign,
>bool with_irqfd);
> +
> +int virtio_pci_add_shm_cap(VirtIOPCIProxy *proxy, uint8_t bar, uint64_t
> offset,
> + uint64_t length, uint8_t id);
> +
> #endif
> --
> 2.41.0.640.ga95def55d0-goog
>
Re: [PATCH v4 6/9] gfxstream + rutabaga: add initial support for gfxstream
On Wed, Aug 09, 2023 at 10:11:05AM +0800, Gurchetan Singh wrote:
> This adds initial support for gfxstream and cross-domain. Both
> features rely on virtio-gpu blob resources and context types, which
> are also implemented in this patch.
>
> gfxstream has a long and illustrious history in Android graphics
> paravirtualization. It has been powering graphics in the Android
> Studio Emulator for more than a decade, which is the main developer
> platform.
>
> Originally conceived by Jesse Hall, it was first known as "EmuGL" [a].
> The key design characteristic was a 1:1 threading model and
> auto-generation, which fit nicely with the OpenGLES spec. It also
> allowed easy layering with ANGLE on the host, which provides the GLES
> implementations on Windows or MacOS enviroments.
>
> gfxstream has traditionally been maintained by a single engineer, and
> between 2015 to 2021, the goldfish throne passed to Frank Yang.
> Historians often remark this glorious reign ("pax gfxstreama" is the
> academic term) was comparable to that of Augustus and both Queen
> Elizabeths. Just to name a few accomplishments in a resplendent
> panoply: higher versions of GLES, address space graphics, snapshot
> support and CTS compliant Vulkan [b].
>
> One major drawback was the use of out-of-tree goldfish drivers.
> Android engineers didn't know much about DRM/KMS and especially TTM so
> a simple guest to host pipe was conceived.
>
> Luckily, virtio-gpu 3D started to emerge in 2016 due to the work of
> the Mesa/virglrenderer communities. In 2018, the initial virtio-gpu
> port of gfxstream was done by Cuttlefish enthusiast Alistair Delva.
> It was a symbol compatible replacement of virglrenderer [c] and named
> "AVDVirglrenderer". This implementation forms the basis of the
> current gfxstream host implementation still in use today.
>
> cross-domain support follows a similar arc. Originally conceived by
> Wayland aficionado David Reveman and crosvm enjoyer Zach Reizner in
> 2018, it initially relied on the downstream "virtio-wl" device.
>
> In 2020 and 2021, virtio-gpu was extended to include blob resources
> and multiple timelines by yours truly, features gfxstream/cross-domain
> both require to function correctly.
>
> Right now, we stand at the precipice of a truly fantastic possibility:
> the Android Emulator powered by upstream QEMU and upstream Linux
> kernel. gfxstream will then be packaged properfully, and app
> developers can even fix gfxstream bugs on their own if they encounter
> them.
>
> It's been quite the ride, my friends. Where will gfxstream head next,
> nobody really knows. I wouldn't be surprised if it's around for
> another decade, maintained by a new generation of Android graphics
> enthusiasts.
>
> Technical details:
> - Very simple initial display integration: just used Pixman
> - Largely, 1:1 mapping of virtio-gpu hypercalls to rutabaga function
> calls
>
> Next steps for Android VMs:
> - The next step would be improving display integration and UI interfaces
> with the goal of the QEMU upstream graphics being in an emulator
> release [d].
>
> Next steps for Linux VMs for display virtualization:
> - For widespread distribution, someone needs to package Sommelier or the
> wayland-proxy-virtwl [e] ideally into Debian main. In addition, newer
> versions of the Linux kernel come with DRM_VIRTIO_GPU_KMS option,
> which allows disabling KMS hypercalls. If anyone cares enough, it'll
> probably be possible to build a custom VM variant that uses this display
> virtualization strategy.
>
> [a] https://android-review.googlesource.com/c/platform/development/+/34470
> [b]
> https://android-review.googlesource.com/q/topic:%22vulkan-hostconnection-start%22
> [c]
> https://android-review.googlesource.com/c/device/generic/goldfish-opengl/+/761927
> [d] https://developer.android.com/studio/releases/emulator
> [e] https://github.com/talex5/wayland-proxy-virtwl
>
> Signed-off-by: Gurchetan Singh
> Tested-by: Alyssa Ross
> ---
> v1: Incorported various suggestions by Akihiko Odaki and Bernard Berschow
> - Removed GET_VIRTIO_GPU_GL / GET_RUTABAGA macros
> - Used error_report(..)
> - Used g_autofree to fix leaks on error paths
> - Removed unnecessary casts
> - added virtio-gpu-pci-rutabaga.c + virtio-vga-rutabaga.c files
>
> v2: Incorported various suggestions by Akihiko Odaki, Marc-André Lureau and
> Bernard Berschow:
> - Parenthesis in CHECK macro
> - CHECK_RESULT(result, ..) --> CHECK(!result, ..)
> - delay until g->parent_obj.enable = 1
> - Additional cast fixes
> - initialize directly in virtio_gpu_rutabaga_realize(..)
> - add debug callback to hook into QEMU error's APIs
>
> v3: Incorporated feedback from Akihiko Odaki and Alyssa Ross:
> - Autodetect Wayland socket when not explicitly specified
> - Fix map_blob error paths
> - Add comment why we need both `res` and `resource` in create blob
> - Cast
Re: [PATCH v3 0/9] gfxstream + rutabaga_gfx
On Wed, Aug 09, 2023 at 09:50:29AM +0800, Gurchetan Singh wrote: >On Mon, Aug 7, 2023 at 7:24 AM Erico Nunes <[1]ernu...@redhat.com> >wrote: > > Hello, > On 04/08/2023 01:54, Gurchetan Singh wrote: > > Prior versions: > > > > > [2]https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg05801.ht > ml > > > > > [3]https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02341.ht > ml > > > > > [4]https://patchew.org/QEMU/20230421011223.718-1-gurchetansingh@chro > mium.org/ > > > > Changes since v2: > > - Incorporated review feedback > > > > How to build both rutabaga and gfxstream guest/host libs: > > > > [5]https://crosvm.dev/book/appendix/rutabaga_gfx.html > > > > Branch containing this patch series: > > > > > [6]https://gitlab.freedesktop.org/gurchetansingh/qemu-gfxstream/-/co > mmits/qemu-gfxstream-v3 > I tried this on Fedora with a Fedora guest and I was able to get > Vulkan > headless applications as well as Wayland proxy with sommelier to > work. > If you don't mind, I have a few questions. > I was not able to run Vulkan applications over the Wayland proxy, > only > unaccelerated apps. This seems to be unsupported yet; is actually > unsupported for now or was something missing in my setup? > >Yes, currently this is unsupported. In the near future, I do imagine >3D accelerated rendering over cross-domain to be a thing (among many >context types, not just gfxstream VK). >Re: using gfxstream VK in Linux distros, depends on your use case. If >you are looking for best performance over virtio on open-source Linux >platforms, perhaps gfxstream Vulkan (or any API virtualization >solution) is not your best bet. The Mesa native context work looks >particularly exciting there: >[7]https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 In fact, we will introduce both venus and virtio native context next step with qemu. :-) I am cleanning up the codes will send out the qemu very soon. Thanks, Ray >We are interested in running gfxstream VK in Linux guests, but we >envisage that for reference and testing. For all embedded use cases, >using the host driver in the guest will predominate due to performance >considerations (either through virtio or HW direct / mediated >passthru). > > Also apparently GL/GLES is only supported on Android right now as > you > mentioned, since on Linux the gfxstream guest only installs the > Vulkan > library and icd. What is the plan to support GL on Linux; provide > gfxstream GL guest libraries later or enable Zink or some other > solution? > Then if I understand correctly, Mesa virgl is not used at all with > the > gfxstream solution, so I guess we would need to find a way to ship > the > gfxstream guest libraries too on distributions? > > > > Also I wonder about including all of the the dependencies required > to > get this to build on distributions as well to enable the feature on > distribution-provided qemu, but I guess we can figure this out > later... > And finally out of curiosity, I see that rutabaga also has a > virgl_renderer (and virgl_renderer_next) backend which would then > not > use gfxstream but virglrenderer instead. I wonder if there would be > any > benefit/features in enabling that with qemu later compared to the > current qemu virtio/virglrenderer implementation (if that would make > sense at all)? > >Yeah, maybe later if there's developer interest, rutabaga FFI can >build its virglrenderer bindings in a subsequent release. So far I >don't have time to test, and the most important use case is gfxstream + >Android for Emulator. As ever, patches are welcome. > > Thanks > Erico > > References > >1. mailto:ernu...@redhat.com >2. https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg05801.html >3. https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02341.html >4. > https://patchew.org/QEMU/20230421011223.718-1-gurchetansi...@chromium.org/ >5. https://crosvm.dev/book/appendix/rutabaga_gfx.html >6. > https://gitlab.freedesktop.org/gurchetansingh/qemu-gfxstream/-/commits/qemu-gfxstream-v3 >7. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658
Re: [RFC QEMU PATCH 08/18] virtio-gpu: Initialize Venus
On Thu, Mar 16, 2023 at 07:14:47AM +0800, Dmitry Osipenko wrote:
> On 3/13/23 18:55, Huang Rui wrote:
> > On Mon, Mar 13, 2023 at 01:51:03AM +0800, Dmitry Osipenko wrote:
> >> On 3/12/23 12:22, Huang Rui wrote:
> >>> From: Antonio Caggiano
> >>>
> >>> Request Venus when initializing VirGL.
> >>>
> >>> Signed-off-by: Antonio Caggiano
> >>> ---
> >>> hw/display/virtio-gpu-virgl.c | 4
> >>> 1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> >>> index fe03dc916f..f5ce206b93 100644
> >>> --- a/hw/display/virtio-gpu-virgl.c
> >>> +++ b/hw/display/virtio-gpu-virgl.c
> >>> @@ -803,7 +803,11 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> >>> {
> >>> int ret;
> >>>
> >>> +#ifdef VIRGL_RENDERER_VENUS
> >>> +ret = virgl_renderer_init(g, VIRGL_RENDERER_VENUS,
> >>> _gpu_3d_cbs);
> >>> +#else
> >>> ret = virgl_renderer_init(g, 0, _gpu_3d_cbs);
> >>> +#endif
> >>
> >> Note that Venus now requires VIRGL_RENDERER_RENDER_SERVER flag to be
> >> set. Please test the patches with the latest virglrenderer and etc.
> >>
> >> The #ifdef also doesn't allow adding new flags, it should look like:
> >>
> >> #ifdef VIRGL_RENDERER_VENUS
> >> flags |= VIRGL_RENDERER_RENDER_SERVER;
> >> #endif
> >>
> >> ret = virgl_renderer_init(g, flags, _gpu_3d_cbs);
> >
> > In fact, we have rebased to the latest virglrenderer:
> >
> > We check both VIRGL_RENDERER_RENDER_SERVER or VIRGL_RENDERER_VENUS in
> > virglrenderer, alternative of them works.
> >
> > https://gitlab.freedesktop.org/rui/virglrenderer/-/commit/c1322a8a84379b1ef7939f56c6761b0114716f45
>
> All the extra changes you made to virglrenderer that Qemu depends on
> need to go upstream. Please open all the relevant merge requests. Thanks!
>
Dmitry, sorry to late response, I have created relevant merge requests
below:
Virglrenderer:
https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1068
Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22108
I'd appreciate any comments. :-)
Thanks,
Ray
Re: [RFC QEMU PATCH 08/18] virtio-gpu: Initialize Venus
On Mon, Mar 13, 2023 at 01:51:03AM +0800, Dmitry Osipenko wrote:
> On 3/12/23 12:22, Huang Rui wrote:
> > From: Antonio Caggiano
> >
> > Request Venus when initializing VirGL.
> >
> > Signed-off-by: Antonio Caggiano
> > ---
> > hw/display/virtio-gpu-virgl.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> > index fe03dc916f..f5ce206b93 100644
> > --- a/hw/display/virtio-gpu-virgl.c
> > +++ b/hw/display/virtio-gpu-virgl.c
> > @@ -803,7 +803,11 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> > {
> > int ret;
> >
> > +#ifdef VIRGL_RENDERER_VENUS
> > +ret = virgl_renderer_init(g, VIRGL_RENDERER_VENUS, _gpu_3d_cbs);
> > +#else
> > ret = virgl_renderer_init(g, 0, _gpu_3d_cbs);
> > +#endif
>
> Note that Venus now requires VIRGL_RENDERER_RENDER_SERVER flag to be
> set. Please test the patches with the latest virglrenderer and etc.
>
> The #ifdef also doesn't allow adding new flags, it should look like:
>
> #ifdef VIRGL_RENDERER_VENUS
> flags |= VIRGL_RENDERER_RENDER_SERVER;
> #endif
>
> ret = virgl_renderer_init(g, flags, _gpu_3d_cbs);
In fact, we have rebased to the latest virglrenderer:
We check both VIRGL_RENDERER_RENDER_SERVER or VIRGL_RENDERER_VENUS in
virglrenderer, alternative of them works.
https://gitlab.freedesktop.org/rui/virglrenderer/-/commit/c1322a8a84379b1ef7939f56c6761b0114716f45
Thanks,
Ray
Re: [RFC QEMU PATCH 08/18] virtio-gpu: Initialize Venus
On Mon, Mar 13, 2023 at 10:22:24AM +0800, Dmitry Osipenko wrote:
> On 3/12/23 20:51, Dmitry Osipenko wrote:
> > On 3/12/23 12:22, Huang Rui wrote:
> >> From: Antonio Caggiano
> >>
> >> Request Venus when initializing VirGL.
> >>
> >> Signed-off-by: Antonio Caggiano
> >> ---
> >> hw/display/virtio-gpu-virgl.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
> >> index fe03dc916f..f5ce206b93 100644
> >> --- a/hw/display/virtio-gpu-virgl.c
> >> +++ b/hw/display/virtio-gpu-virgl.c
> >> @@ -803,7 +803,11 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
> >> {
> >> int ret;
> >>
> >> +#ifdef VIRGL_RENDERER_VENUS
> >> +ret = virgl_renderer_init(g, VIRGL_RENDERER_VENUS,
> >> _gpu_3d_cbs);
> >> +#else
> >> ret = virgl_renderer_init(g, 0, _gpu_3d_cbs);
> >> +#endif
> >
> > Note that Venus now requires VIRGL_RENDERER_RENDER_SERVER flag to be
> > set. Please test the patches with the latest virglrenderer and etc.
> >
> > The #ifdef also doesn't allow adding new flags, it should look like:
> >
> > #ifdef VIRGL_RENDERER_VENUS
> > flags |= VIRGL_RENDERER_RENDER_SERVER;
> > #endif
> >
> > ret = virgl_renderer_init(g, flags, _gpu_3d_cbs);
> >
>
> BTW, Alex reviewed the Venus v3 patches a month ago [1] and the review
> comments need to be addressed. AFAICS, you're actually using the very
> old Venus patches here that stopped working about a year ago, so again
> you're using a very outdated virglrenderer version.
>
> Please take it all into account if you'll beat me to posting the next
> version of Venus patches ;)
>
> [1]
> https://lore.kernel.org/qemu-devel/20220926142422.22325-1-antonio.caggi...@collabora.com/
>
Thanks Dmitry point it out, I will use the latest v3 patches, and try to
address the comments in next version. :-)
Thanks,
Ray
[RFC QEMU PATCH 00/18] Add VirtIO GPU and Passthrough GPU support on Xen
Hi all, We are working to introduce VirtIO GPU and Passthrough GPU support on Xen. https://lists.xenproject.org/archives/html/xen-devel/2023-03/msg00714.html Currently, only virgl for VirtIO GPU and Passthrough GPU on PV dom0 can works on Xen. These series introduce more graphic support for Xen on QEMU part. 1) Add Venus with QEMU for VirtIO GPU on Xen Antonio Caggiano made the venus with QEMU on KVM platform below, patch 1 to 11 are inherited from his original work to support the features of context init, hostmem, resource uuid, and blob resources for Venus. We have rebase the support to the latest version. https://www.collabora.com/news-and-blog/blog/2021/11/26/venus-on-qemu-enabling-new-virtual-vulkan-driver/ But on Xen, it still needs to add "-mem-path" function in the QEMU. Because it requires the memory-backend-memfd support. Please check patch 12 to 16. With the Venus supported on Xen, we can enable Zink + Venus for OpenGL rendering on guest domU as well. 2) Add Video hardware accelerate support for virgl Please check patch 17, that adds get_drm_fd callback to let guest know hardware accel codec is used. 3) Enable Passthrough GPU on Xen PVH dom0 in QEMU Please check patch 18, that translate host irq to gsi for PCIe Passthrough on PVH dom0. Below are the screenshot of these functions, please take a look. Venus: https://drive.google.com/file/d/1_lPq6DMwHu1JQv7LUUVRx31dBj0HJYcL/view?usp=share_link Zink: https://drive.google.com/file/d/1FxLmKu6X7uJOxx1ZzwOm1yA6IL5WMGzd/view?usp=share_link Passthrough GPU: https://drive.google.com/file/d/17onr5gvDK8KM_LniHTSQEI2hGJZlI09L/view?usp=share_link Repositories Kernel: https://git.kernel.org/pub/scm/linux/kernel/git/rui/linux.git/log/?h=upstream-fox-xen Xen: https://gitlab.com/huangrui123/xen/-/commits/upstream-for-xen QEMU: https://gitlab.com/huangrui123/qemu/-/commits/upstream-for-xen Mesa: https://gitlab.freedesktop.org/rui/mesa/-/commits/upstream-for-xen Virglrenderer: https://gitlab.freedesktop.org/rui/virglrenderer/-/commits/upstream-for-xen Thanks, Ray Antonio Caggiano (8): virtio-gpu: Handle resource blob commands virtio-gpu: CONTEXT_INIT feature virtio-gpu: Unrealize virtio-gpu: Resource UUID virtio-gpu: Support Venus capset virtio-gpu: Initialize Venus meson: Enable virglrenderer unstable APIs virtio-gpu: Handle set scanout blob command Chen Jiqian (1): xen: translate irq of host pci device to gsi Dr. David Alan Gilbert (1): virtio: Add shared memory capability Gerd Hoffmann (1): virtio-gpu: hostmem Honglei Huang (2): virtio-gpu: fix hw-display-virtio-gpu.so undefined symbol virtio_gpu_virgl_resource_unmap virtio-gpu: Add video hardware accelerate support for virgl Huang Rui (4): softmmu: Fix the size to map cache with xen for host virtual address hw/i386/xen/xen-hvm: Introduce xen_ram_block_check function softmmu: Add ram block check to map the xen ram memory softmmu: Enable qemu ram allocation with fd for Xen Robert Beckett (1): virtio-gpu: make blob scanout use dmabuf fd hw/display/meson.build | 2 +- hw/display/trace-events | 1 + hw/display/virtio-gpu-base.c| 7 +- hw/display/virtio-gpu-pci.c | 14 + hw/display/virtio-gpu-virgl.c | 326 +++- hw/display/virtio-gpu.c | 101 +- hw/display/virtio-vga.c | 33 +- hw/i386/xen/xen-hvm.c | 15 + hw/virtio/virtio-pci.c | 18 ++ hw/xen/xen-host-pci-device.c| 3 +- include/hw/virtio/virtio-gpu-bswap.h| 18 ++ include/hw/virtio/virtio-gpu.h | 28 ++ include/hw/virtio/virtio-pci.h | 4 + include/hw/xen/xen.h| 1 + include/standard-headers/linux/virtio_gpu.h | 2 + meson.build | 11 + softmmu/physmem.c | 12 +- 17 files changed, 559 insertions(+), 37 deletions(-) -- 2.25.1
[RFC QEMU PATCH 06/18] virtio-gpu: Resource UUID
From: Antonio Caggiano
Enable resource UUID feature and implement command resource assign UUID.
This is done by introducing a hash table to map resource IDs to their
UUIDs.
Signed-off-by: Antonio Caggiano
---
hw/display/trace-events| 1 +
hw/display/virtio-gpu-base.c | 2 ++
hw/display/virtio-gpu-virgl.c | 11 +
hw/display/virtio-gpu.c| 41 ++
include/hw/virtio/virtio-gpu.h | 4
5 files changed, 59 insertions(+)
diff --git a/hw/display/trace-events b/hw/display/trace-events
index 0c0ffcbe42..6632344322 100644
--- a/hw/display/trace-events
+++ b/hw/display/trace-events
@@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t size)
"res 0x%x, size %" P
virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
+virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index 5cb71e71ad..54792aa501 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -219,6 +219,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
}
+features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
+
return features;
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 41712b79ee..a3c388f907 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -45,6 +45,10 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
args.nr_samples = 0;
args.flags = VIRTIO_GPU_RESOURCE_FLAG_Y_0_TOP;
virgl_renderer_resource_create(, NULL, 0);
+
+struct virtio_gpu_simple_resource *res = g_new0(struct
virtio_gpu_simple_resource, 1);
+res->resource_id = c2d.resource_id;
+QTAILQ_INSERT_HEAD(>reslist, res, next);
}
static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
@@ -69,6 +73,10 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
args.nr_samples = c3d.nr_samples;
args.flags = c3d.flags;
virgl_renderer_resource_create(, NULL, 0);
+
+struct virtio_gpu_simple_resource *res = g_new0(struct
virtio_gpu_simple_resource, 1);
+res->resource_id = c3d.resource_id;
+QTAILQ_INSERT_HEAD(>reslist, res, next);
}
static void virgl_cmd_resource_unref(VirtIOGPU *g,
@@ -621,6 +629,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
/* TODO add security */
virgl_cmd_ctx_detach_resource(g, cmd);
break;
+case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
+virtio_gpu_resource_assign_uuid(g, cmd);
+break;
case VIRTIO_GPU_CMD_GET_CAPSET_INFO:
virgl_cmd_get_capset_info(g, cmd);
break;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 62239dee0f..c7d1e52cb5 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -940,6 +940,37 @@ virtio_gpu_resource_detach_backing(VirtIOGPU *g,
virtio_gpu_cleanup_mapping(g, res);
}
+void virtio_gpu_resource_assign_uuid(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_simple_resource *res;
+struct virtio_gpu_resource_assign_uuid assign;
+struct virtio_gpu_resp_resource_uuid resp;
+QemuUUID *uuid = NULL;
+
+VIRTIO_GPU_FILL_CMD(assign);
+virtio_gpu_bswap_32(, sizeof(assign));
+trace_virtio_gpu_cmd_res_assign_uuid(assign.resource_id);
+
+res = virtio_gpu_find_check_resource(g, assign.resource_id, false,
__func__, >error);
+if (!res) {
+return;
+}
+
+memset(, 0, sizeof(resp));
+resp.hdr.type = VIRTIO_GPU_RESP_OK_RESOURCE_UUID;
+
+uuid = g_hash_table_lookup(g->resource_uuids,
GUINT_TO_POINTER(assign.resource_id));
+if (!uuid) {
+uuid = g_new(QemuUUID, 1);
+qemu_uuid_generate(uuid);
+g_hash_table_insert(g->resource_uuids,
GUINT_TO_POINTER(assign.resource_id), uuid);
+}
+
+memcpy(resp.uuid, uuid, sizeof(QemuUUID));
+virtio_gpu_ctrl_response(g, cmd, , sizeof(resp));
+}
+
void virtio_gpu_simple_process_cmd(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
@@ -988,6 +1019,9 @@ void virtio_gpu_simple_process_cmd(VirtIOGPU *g,
case VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING:
virtio_gpu_resource_detach_backing(g, cmd);
break;
+case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
+virtio_gpu_resource_assign_uuid(g, cmd);
+break;
default:
cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
break;
@@ -1348,12 +1382,15 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error
**errp)
QTAILQ_INIT(>reslist);
QTAILQ_INIT(>cmdq);
[RFC QEMU PATCH 09/18] meson: Enable virglrenderer unstable APIs
From: Antonio Caggiano
Also, use alternatives to meson compiler has_function, which does not
work properly on my development environment.
Signed-off-by: Antonio Caggiano
---
meson.build | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meson.build b/meson.build
index 826b3473c4..8cd453844f 100644
--- a/meson.build
+++ b/meson.build
@@ -774,13 +774,16 @@ if not get_option('virglrenderer').auto() or have_system
or have_vhost_user_gpu
method: 'pkg-config',
required: get_option('virglrenderer'),
kwargs: static_kwargs)
+ virgl = declare_dependency(compile_args: '-DVIRGL_RENDERER_UNSTABLE_APIS',
+ dependencies: virgl)
+
config_host_data.set('HAVE_VIRGL_RESOURCE_BLOB',
- cc.has_function('virgl_renderer_resource_create_blob',
+ cc.has_type('struct
virgl_renderer_resource_create_blob_args',
prefix: '#include ',
dependencies: virgl))
config_host_data.set('HAVE_VIRGL_CONTEXT_INIT',
-
cc.has_function('virgl_renderer_context_create_with_flags',
- prefix: '#include ',
+ cc.has_header_symbol('virglrenderer.h',
+
'VIRGL_RENDERER_CONTEXT_FLAG_CAPSET_ID_MASK',
dependencies: virgl))
endif
blkio = not_found
--
2.25.1
[RFC QEMU PATCH 14/18] softmmu: Add ram block check to map the xen ram memory
The xen ram memory should be mapped with addr instead of ramblock
offset. So we need to add a check to make sure current ramblock is xen
ram memory.
Signed-off-by: Huang Rui
---
softmmu/physmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/softmmu/physmem.c b/softmmu/physmem.c
index 1b0bb35da9..e54561bace 100644
--- a/softmmu/physmem.c
+++ b/softmmu/physmem.c
@@ -2333,7 +2333,7 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block,
ram_addr_t addr,
* because we don't want to map the entire memory in QEMU.
* In that case just map the requested area.
*/
-if (block->offset == 0) {
+if (block->offset == 0 || (!lock && xen_ram_block_check(block))) {
return xen_map_cache(addr, *size, lock, lock);
}
--
2.25.1
[RFC QEMU PATCH 16/18] virtio-gpu: fix hw-display-virtio-gpu.so undefined symbol virtio_gpu_virgl_resource_unmap
From: Honglei Huang
Move virtio_gpu_virgl_resource_unmap to virtio-gpu.c cause virtio-gpu.so
call this function but this function in virtio-gpu-gl.so before.
Add virgl dependency into virtio-gpu-gl.so.
Suggested-by: Stefano Stabellini
Signed-off-by: Honglei Huang
Reviewed-by: Huang Rui
Signed-off-by: Huang Rui
---
hw/display/meson.build| 2 +-
hw/display/virtio-gpu-virgl.c | 17 -
hw/display/virtio-gpu.c | 19 +++
3 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/hw/display/meson.build b/hw/display/meson.build
index 7a725ed80e..21999dfbe0 100644
--- a/hw/display/meson.build
+++ b/hw/display/meson.build
@@ -67,7 +67,7 @@ softmmu_ss.add(when: [pixman, 'CONFIG_ATI_VGA'], if_true:
files('ati.c', 'ati_2d
if config_all_devices.has_key('CONFIG_VIRTIO_GPU')
virtio_gpu_ss = ss.source_set()
virtio_gpu_ss.add(when: 'CONFIG_VIRTIO_GPU',
-if_true: [files('virtio-gpu-base.c', 'virtio-gpu.c'),
pixman])
+if_true: [files('virtio-gpu-base.c', 'virtio-gpu.c'),
pixman, virgl])
virtio_gpu_ss.add(when: 'CONFIG_LINUX', if_true:
files('virtio-gpu-udmabuf.c'),
if_false:
files('virtio-gpu-udmabuf-stubs.c'))
virtio_gpu_ss.add(when: 'CONFIG_VHOST_USER_GPU', if_true:
files('vhost-user-gpu.c'))
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 69083d15a9..d5214e0f43 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -636,23 +636,6 @@ static void virgl_cmd_resource_map_blob(VirtIOGPU *g,
virtio_gpu_ctrl_response(g, cmd, , sizeof(resp));
}
-int virtio_gpu_virgl_resource_unmap(VirtIOGPU *g,
-struct virtio_gpu_simple_resource *res)
-{
-if (!res->mapped) {
-qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already unmapped %d\n",
- __func__, res->resource_id);
-return VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
-}
-
-memory_region_set_enabled(>region, false);
-memory_region_del_subregion(>parent_obj.hostmem, >region);
-object_unparent(OBJECT(>region));
-
-res->mapped = NULL;
-return virgl_renderer_resource_unmap(res->resource_id);
-}
-
static void virgl_cmd_resource_unmap_blob(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 95e421a525..95eaed61b3 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -31,6 +31,8 @@
#include "qapi/error.h"
#include "qemu/error-report.h"
+#include
+
#define VIRTIO_GPU_VM_VERSION 1
static struct virtio_gpu_simple_resource *
@@ -873,6 +875,23 @@ void virtio_gpu_cleanup_mapping_iov(VirtIOGPU *g,
g_free(iov);
}
+int virtio_gpu_virgl_resource_unmap(VirtIOGPU *g,
+struct virtio_gpu_simple_resource *res)
+{
+if (!res->mapped) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already unmapped %d\n",
+ __func__, res->resource_id);
+return VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+}
+
+memory_region_set_enabled(>region, false);
+memory_region_del_subregion(>parent_obj.hostmem, >region);
+object_unparent(OBJECT(>region));
+
+res->mapped = NULL;
+return virgl_renderer_resource_unmap(res->resource_id);
+}
+
static void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
struct virtio_gpu_simple_resource *res)
{
--
2.25.1
[RFC QEMU PATCH 13/18] hw/i386/xen/xen-hvm: Introduce xen_ram_block_check function
Introduce xen_ram_block_check function to check whether current ramblock
is xen ram memory.
Signed-off-by: Huang Rui
---
hw/i386/xen/xen-hvm.c | 15 +++
include/hw/xen/xen.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index e4293d6d66..a4f12aefce 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -32,6 +32,7 @@
#include "sysemu/xen.h"
#include "sysemu/xen-mapcache.h"
#include "trace.h"
+#include "include/exec/ramblock.h"
#include
#include
@@ -1564,6 +1565,20 @@ void xen_register_framebuffer(MemoryRegion *mr)
framebuffer = mr;
}
+bool xen_ram_block_check(RAMBlock *rb)
+{
+ bool ret;
+
+ if (!rb)
+ return false;
+
+ ret = (rb == ram_memory.ram_block);
+ if (ret)
+ rb->offset = 0;
+
+ return ret;
+}
+
void xen_shutdown_fatal_error(const char *fmt, ...)
{
va_list ap;
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index afdf9c436a..99a383eb17 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -31,5 +31,6 @@ qemu_irq *xen_interrupt_controller_init(void);
void xenstore_store_pv_console_info(int i, Chardev *chr);
void xen_register_framebuffer(struct MemoryRegion *mr);
+bool xen_ram_block_check(RAMBlock *rb);
#endif /* QEMU_HW_XEN_H */
--
2.25.1
[RFC QEMU PATCH 10/18] virtio-gpu: Handle set scanout blob command
From: Antonio Caggiano
Use mapped data pointer as data for the scanout.
Signed-off-by: Antonio Caggiano
---
hw/display/virtio-gpu-virgl.c | 3 +++
hw/display/virtio-gpu.c| 11 +++
include/hw/virtio/virtio-gpu.h | 2 ++
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index f5ce206b93..1fe144f64d 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -653,6 +653,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
case VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB:
virgl_cmd_resource_create_blob(g, cmd);
break;
+case VIRTIO_GPU_CMD_SET_SCANOUT_BLOB:
+virtio_gpu_set_scanout_blob(g, cmd);
+break;
case VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB:
virgl_cmd_resource_map_blob(g, cmd);
break;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index c7d1e52cb5..1e334a1e78 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -144,7 +144,7 @@ virtio_gpu_find_check_resource(VirtIOGPU *g, uint32_t
resource_id,
}
if (require_backing) {
-if (!res->iov || (!res->image && !res->blob)) {
+if (!res->iov || (!res->image && !res->blob) || !res->mapped) {
qemu_log_mask(LOG_GUEST_ERROR, "%s: no backing storage %d\n",
caller, resource_id);
if (error) {
@@ -637,7 +637,10 @@ static void virtio_gpu_do_set_scanout(VirtIOGPU *g,
}
data = res->blob;
-} else {
+} else if (res->mapped) {
+data = (uint8_t *)res->mapped;
+}
+else {
data = (uint8_t *)pixman_image_get_data(res->image);
}
@@ -714,8 +717,8 @@ static void virtio_gpu_set_scanout(VirtIOGPU *g,
, res, , >error);
}
-static void virtio_gpu_set_scanout_blob(VirtIOGPU *g,
-struct virtio_gpu_ctrl_command *cmd)
+void virtio_gpu_set_scanout_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
{
struct virtio_gpu_simple_resource *res;
struct virtio_gpu_framebuffer fb = { 0 };
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 0a44aea4ee..ce49cdfafb 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -284,6 +284,8 @@ void virtio_gpu_simple_process_cmd(VirtIOGPU *g, struct
virtio_gpu_ctrl_command
void virtio_gpu_update_cursor_data(VirtIOGPU *g,
struct virtio_gpu_scanout *s,
uint32_t resource_id);
+void virtio_gpu_set_scanout_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd);
/* virtio-gpu-udmabuf.c */
bool virtio_gpu_have_udmabuf(void);
--
2.25.1
[RFC QEMU PATCH 18/18] xen: translate irq of host pci device to gsi
From: Chen Jiqian
Use the new interface in the kernel to map pirq for qemu.
Signed-off-by: Chen Jiqian
Signed-off-by: Huang Rui
---
hw/xen/xen-host-pci-device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index 8c6e9a1716..6ca841a967 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -9,6 +9,7 @@
#include "qemu/osdep.h"
#include "qapi/error.h"
#include "qemu/cutils.h"
+#include "hw/xen/xen_common.h"
#include "xen-host-pci-device.h"
#define XEN_HOST_PCI_MAX_EXT_CAP \
@@ -368,7 +369,7 @@ void xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t
domain,
if (*errp) {
goto error;
}
-d->irq = v;
+d->irq = xc_physdev_gsi_from_irq(xen_xc, v);
xen_host_pci_get_hex_value(d, "class", , errp);
if (*errp) {
--
2.25.1
[RFC QEMU PATCH 17/18] virtio-gpu: Add video hardware accelerate support for virgl
From: Honglei Huang
Add get_drm_fd callback let the guest OS can get render node to using hw accel
codec.
Signed-off-by: Honglei Huang
Signed-off-by: Huang Rui
---
hw/display/virtio-gpu-virgl.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index d5214e0f43..aef735a427 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -13,6 +13,7 @@
#include "qemu/osdep.h"
#include "qemu/iov.h"
+#include "qemu/drm.h"
#include "trace.h"
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-gpu.h"
@@ -827,12 +828,22 @@ static int virgl_make_context_current(void *opaque, int
scanout_idx,
qctx);
}
+static int virgl_get_drm_fd(void *opaque)
+{
+int fd = -1;
+
+fd = qemu_drm_rendernode_open(NULL);
+
+return fd;
+}
+
static struct virgl_renderer_callbacks virtio_gpu_3d_cbs = {
.version = 1,
.write_fence = virgl_write_fence,
.create_gl_context = virgl_create_context,
.destroy_gl_context = virgl_destroy_context,
.make_current= virgl_make_context_current,
+.get_drm_fd = virgl_get_drm_fd,
};
static void virtio_gpu_print_stats(void *opaque)
@@ -886,14 +897,20 @@ void virtio_gpu_virgl_reset(VirtIOGPU *g)
virgl_renderer_reset();
}
+
+
int virtio_gpu_virgl_init(VirtIOGPU *g)
{
int ret;
+#ifndef VIRGL_RENDERER_USE_VIDEO
+#define VIRGL_RENDERER_USE_VIDEO (1 << 11)
+#endif
+
#ifdef VIRGL_RENDERER_VENUS
-ret = virgl_renderer_init(g, VIRGL_RENDERER_VENUS, _gpu_3d_cbs);
+ret = virgl_renderer_init(g, VIRGL_RENDERER_VENUS |
VIRGL_RENDERER_USE_VIDEO, _gpu_3d_cbs);
#else
-ret = virgl_renderer_init(g, 0, _gpu_3d_cbs);
+ret = virgl_renderer_init(g, 0 | VIRGL_RENDERER_USE_VIDEO,
_gpu_3d_cbs);
#endif
if (ret != 0) {
error_report("virgl could not be initialized: %d", ret);
--
2.25.1
[RFC QEMU PATCH 07/18] virtio-gpu: Support Venus capset
From: Antonio Caggiano
Add support for the Venus capset, which enables Vulkan support through
the Venus Vulkan driver for virtio-gpu.
Signed-off-by: Antonio Caggiano
---
hw/display/virtio-gpu-virgl.c | 21 +
include/standard-headers/linux/virtio_gpu.h | 2 ++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index a3c388f907..fe03dc916f 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -388,6 +388,11 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
virgl_renderer_get_cap_set(resp.capset_id,
_max_version,
_max_size);
+} else if (info.capset_index == 2) {
+resp.capset_id = VIRTIO_GPU_CAPSET_VENUS;
+virgl_renderer_get_cap_set(resp.capset_id,
+ _max_version,
+ _max_size);
} else {
resp.capset_max_version = 0;
resp.capset_max_size = 0;
@@ -817,10 +822,18 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
{
-uint32_t capset2_max_ver, capset2_max_size;
+uint32_t capset2_max_ver, capset2_max_size, num_capsets;
+num_capsets = 1;
+
virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
- _max_ver,
- _max_size);
+ _max_ver,
+ _max_size);
+num_capsets += capset2_max_ver ? 1 : 0;
+
+virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
+ _max_ver,
+ _max_size);
+num_capsets += capset2_max_size ? 1 : 0;
-return capset2_max_ver ? 2 : 1;
+return num_capsets;
}
diff --git a/include/standard-headers/linux/virtio_gpu.h
b/include/standard-headers/linux/virtio_gpu.h
index 2da48d3d4c..2db643ed8f 100644
--- a/include/standard-headers/linux/virtio_gpu.h
+++ b/include/standard-headers/linux/virtio_gpu.h
@@ -309,6 +309,8 @@ struct virtio_gpu_cmd_submit {
#define VIRTIO_GPU_CAPSET_VIRGL 1
#define VIRTIO_GPU_CAPSET_VIRGL2 2
+/* 3 is reserved for gfxstream */
+#define VIRTIO_GPU_CAPSET_VENUS 4
/* VIRTIO_GPU_CMD_GET_CAPSET_INFO */
struct virtio_gpu_get_capset_info {
--
2.25.1
[RFC QEMU PATCH 12/18] softmmu: Fix the size to map cache with xen for host virtual address
The xen_map_cache function wants to pass offset and size of this memory
block as the input parameters to map the host virtual address. However,
block->offset is too large as 0x1 (4G), if we assign the size as
block->max_length (0x11000), the mapped host address will be out of
block->max_length and easy to overflow. We have to assign the size as
(block->max_length - block->offset), then that is able to ensure the
address will be located in legal range inside of max_length.
{rcu = {next = 0x0, func = 0x0}, mr = 0x5681b620, host = 0x0,
colo_cache = 0x0, offset = 0x1, used_length = 0x11000,
max_length = 0x11000, resized = 0x0, flags = 0x10, idstr = {0x78,
0x65, 0x6e, 0x2e, 0x72, 0x61, 0x6d, 0x0 }, next = {
le_next = 0x568c61b0, le_prev = 0x5681c640},
ramblock_notifiers = {lh_first = 0x0}, fd = 0x, page_size =
0x1000, bmap = 0x0, receivedmap = 0x0, clear_bmap = 0x0,
clear_bmap_shift = 0x0, postcopy_length = 0x0}
Signed-off-by: Huang Rui
---
softmmu/physmem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/softmmu/physmem.c b/softmmu/physmem.c
index 1b606a3002..1b0bb35da9 100644
--- a/softmmu/physmem.c
+++ b/softmmu/physmem.c
@@ -2304,7 +2304,7 @@ void *qemu_map_ram_ptr(RAMBlock *ram_block, ram_addr_t
addr)
return xen_map_cache(addr, 0, 0, false);
}
-block->host = xen_map_cache(block->offset, block->max_length, 1,
false);
+ block->host = xen_map_cache(block->offset, block->max_length, 1, false);
}
return ramblock_ptr(block, addr);
}
@@ -2337,7 +2337,8 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block,
ram_addr_t addr,
return xen_map_cache(addr, *size, lock, lock);
}
-block->host = xen_map_cache(block->offset, block->max_length, 1, lock);
+ block->host = xen_map_cache(block->offset,
+ block->max_length - block->offset, 1, lock);
}
return ramblock_ptr(block, addr);
--
2.25.1
[RFC QEMU PATCH 15/18] softmmu: Enable qemu ram allocation with fd for Xen
Venus is requesting the function on Xen as well, enable this path on Xen
hypervisor.
Signed-off-by: Huang Rui
---
softmmu/physmem.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/softmmu/physmem.c b/softmmu/physmem.c
index e54561bace..2838dee2f2 100644
--- a/softmmu/physmem.c
+++ b/softmmu/physmem.c
@@ -2060,11 +2060,6 @@ RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size,
MemoryRegion *mr,
assert((ram_flags & ~(RAM_SHARED | RAM_PMEM | RAM_NORESERVE |
RAM_PROTECTED)) == 0);
-if (xen_enabled()) {
-error_setg(errp, "-mem-path not supported with Xen");
-return NULL;
-}
-
if (kvm_enabled() && !kvm_has_sync_mmu()) {
error_setg(errp,
"host lacks kvm mmu notifiers, -mem-path unsupported");
--
2.25.1
[RFC QEMU PATCH 08/18] virtio-gpu: Initialize Venus
From: Antonio Caggiano
Request Venus when initializing VirGL.
Signed-off-by: Antonio Caggiano
---
hw/display/virtio-gpu-virgl.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index fe03dc916f..f5ce206b93 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -803,7 +803,11 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
{
int ret;
+#ifdef VIRGL_RENDERER_VENUS
+ret = virgl_renderer_init(g, VIRGL_RENDERER_VENUS, _gpu_3d_cbs);
+#else
ret = virgl_renderer_init(g, 0, _gpu_3d_cbs);
+#endif
if (ret != 0) {
error_report("virgl could not be initialized: %d", ret);
return ret;
--
2.25.1
[RFC QEMU PATCH 11/18] virtio-gpu: make blob scanout use dmabuf fd
From: Robert Beckett
This relies on a virglrenderer change to include the dmabuf fd when
returning resource info.
Signed-off-by: Robert Beckett
---
hw/display/virtio-gpu-virgl.c | 103 -
hw/display/virtio-gpu.c| 4 +-
include/hw/virtio/virtio-gpu.h | 5 ++
3 files changed, 109 insertions(+), 3 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 1fe144f64d..69083d15a9 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -18,6 +18,7 @@
#include "hw/virtio/virtio-gpu.h"
#include "hw/virtio/virtio-gpu-bswap.h"
#include "hw/virtio/virtio-iommu.h"
+#include "hw/virtio/virtio-gpu-pixman.h"
#include
@@ -208,6 +209,106 @@ static void virgl_cmd_set_scanout(VirtIOGPU *g,
g->parent_obj.scanout[ss.scanout_id].resource_id = ss.resource_id;
}
+static void virgl_cmd_set_scanout_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_simple_resource *res;
+struct virtio_gpu_framebuffer fb = { 0 };
+struct virtio_gpu_set_scanout_blob ss;
+struct virgl_renderer_resource_info info;
+uint64_t fbend;
+
+VIRTIO_GPU_FILL_CMD(ss);
+virtio_gpu_scanout_blob_bswap();
+trace_virtio_gpu_cmd_set_scanout_blob(ss.scanout_id, ss.resource_id,
+ ss.r.width, ss.r.height, ss.r.x,
+ ss.r.y);
+
+if (ss.scanout_id >= g->parent_obj.conf.max_outputs) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: illegal scanout id specified %d",
+ __func__, ss.scanout_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_SCANOUT_ID;
+return;
+}
+
+if (ss.resource_id == 0) {
+virtio_gpu_disable_scanout(g, ss.scanout_id);
+return;
+}
+
+if (ss.width < 16 ||
+ ss.height < 16 ||
+ ss.r.x + ss.r.width > ss.width ||
+ ss.r.y + ss.r.height > ss.height) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: illegal scanout %d bounds for"
+ " resource %d, rect (%d,%d)+%d,%d, fb %d %d\n",
+ __func__, ss.scanout_id, ss.resource_id,
+ ss.r.x, ss.r.y, ss.r.width, ss.r.height,
+ ss.width, ss.height);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+return;
+}
+
+if (!console_has_gl(g->parent_obj.scanout[ss.scanout_id].con)) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: unable to scanout blot without
GL!\n", __func__);
+ return;
+}
+
+res = virtio_gpu_find_resource(g, ss.resource_id);
+if (!res) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: illegal resource specified %d\n",
+ __func__, ss.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+if (virgl_renderer_resource_get_info(ss.resource_id, )) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: illegal virgl resource specified %d\n",
+ __func__, ss.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+if (!res->dmabuf_fd && info.fd)
+ res->dmabuf_fd = info.fd;
+
+fb.format = virtio_gpu_get_pixman_format(ss.format);
+if (!fb.format) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: host couldn't handle guest format %d\n",
+ __func__, ss.format);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+return;
+}
+
+fb.bytes_pp = DIV_ROUND_UP(PIXMAN_FORMAT_BPP(fb.format), 8);
+fb.width = ss.width;
+fb.height = ss.height;
+fb.stride = ss.strides[0];
+fb.offset = ss.offsets[0] + ss.r.x * fb.bytes_pp + ss.r.y * fb.stride;
+
+fbend = fb.offset;
+fbend += fb.stride * (ss.r.height - 1);
+fbend += fb.bytes_pp * ss.r.width;
+if (fbend > res->blob_size) {
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: fb end out of range\n",
+ __func__);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+return;
+}
+
+g->parent_obj.enable = 1;
+if (virtio_gpu_update_dmabuf(g, ss.scanout_id, res, , )) {
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: failed to update dmabuf\n", __func__);
+ cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
+ return;
+}
+virtio_gpu_update_scanout(g, ss.scanout_id, res, );
+}
+
+
static void virgl_cmd_submit_3d(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
@@ -654,7 +755,7 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
virgl_cmd_resource_create_blob(g, cmd);
break;
case VIRTIO_GPU_CMD_SET_SCANOUT_BLOB:
-virtio_gpu_set_scanout_blob(g, cmd);
+
[RFC QEMU PATCH 05/18] virtio-gpu: Unrealize
From: Antonio Caggiano
Implement an unrealize function for virtio gpu device.
Signed-off-by: Antonio Caggiano
---
hw/display/virtio-gpu-base.c | 2 +-
hw/display/virtio-gpu.c| 11 +++
include/hw/virtio/virtio-gpu.h | 1 +
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index 6c5f1f327f..5cb71e71ad 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -230,7 +230,7 @@ virtio_gpu_base_set_features(VirtIODevice *vdev, uint64_t
features)
trace_virtio_gpu_features(((features & virgl) == virgl));
}
-static void
+void
virtio_gpu_base_device_unrealize(DeviceState *qdev)
{
VirtIOGPUBase *g = VIRTIO_GPU_BASE(qdev);
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 11f3e56013..62239dee0f 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1350,6 +1350,16 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error
**errp)
QTAILQ_INIT(>fenceq);
}
+static void virtio_gpu_device_unrealize(DeviceState *qdev)
+{
+VirtIOGPU *g = VIRTIO_GPU(qdev);
+
+qemu_bh_delete(g->cursor_bh);
+qemu_bh_delete(g->ctrl_bh);
+
+virtio_gpu_base_device_unrealize(qdev);
+}
+
void virtio_gpu_reset(VirtIODevice *vdev)
{
VirtIOGPU *g = VIRTIO_GPU(vdev);
@@ -1448,6 +1458,7 @@ static void virtio_gpu_class_init(ObjectClass *klass,
void *data)
vgbc->gl_flushed = virtio_gpu_handle_gl_flushed;
vdc->realize = virtio_gpu_device_realize;
+vdc->unrealize = virtio_gpu_device_unrealize;
vdc->reset = virtio_gpu_reset;
vdc->get_config = virtio_gpu_get_config;
vdc->set_config = virtio_gpu_set_config;
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index d1ae97153f..ef02190f97 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -246,6 +246,7 @@ bool virtio_gpu_base_device_realize(DeviceState *qdev,
VirtIOHandleOutput ctrl_cb,
VirtIOHandleOutput cursor_cb,
Error **errp);
+void virtio_gpu_base_device_unrealize(DeviceState *qdev);
void virtio_gpu_base_reset(VirtIOGPUBase *g);
void virtio_gpu_base_fill_display_info(VirtIOGPUBase *g,
struct virtio_gpu_resp_display_info *dpy_info);
--
2.25.1
[RFC QEMU PATCH 03/18] virtio-gpu: Handle resource blob commands
From: Antonio Caggiano
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
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-virgl.c| 168 +++
hw/display/virtio-gpu.c | 12 +-
include/hw/virtio/virtio-gpu-bswap.h | 18 +++
include/hw/virtio/virtio-gpu.h | 8 ++
meson.build | 4 +
5 files changed, 206 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 73cb92c8d5..9b5e3dc782 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -16,6 +16,8 @@
#include "trace.h"
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-gpu.h"
+#include "hw/virtio/virtio-gpu-bswap.h"
+#include "hw/virtio/virtio-iommu.h"
#include
@@ -398,6 +400,161 @@ 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;
+int ret;
+
+VIRTIO_GPU_FILL_CMD(cblob);
+virtio_gpu_create_blob_bswap();
+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);
+QTAILQ_INSERT_HEAD(>reslist, res, next);
+
+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, >addrs, >iov,
+>iov_cnt);
+if (ret != 0) {
+cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
+return;
+}
+}
+
+if (cblob.blob_mem == VIRTIO_GPU_BLOB_MEM_GUEST) {
+virtio_gpu_init_udmabuf(res);
+}
+const struct virgl_renderer_resource_create_blob_args virgl_args = {
+.res_handle = cblob.resource_id,
+.ctx_id = cblob.hdr.ctx_id,
+.blob_mem = cblob.blob_mem,
+.blob_id = cblob.blob_id,
+.blob_flags = cblob.blob_flags,
+.size = cblob.size,
+.iovecs = res->iov,
+.num_iovs = res->iov_cnt,
+};
+ret = virgl_renderer_resource_create_blob(_args);
+if (ret) {
+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;
+uint64_t size;
+struct virtio_gpu_resp_map_info resp;
+
+VIRTIO_GPU_FILL_CMD(mblob);
+virtio_gpu_map_blob_bswap();
+
+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;
+}
+
+ret = virgl_renderer_resource_map(res->resource_id, >mapped, );
+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;
+}
+
+memory_region_init_ram_device_ptr(>region, OBJECT(g), NULL, size,
res->mapped);
+memory_region_add_subregion(>parent_obj.hostmem, mblob.offset,
>region);
+memory_region_set_enabled(>region, true);
+
+memset(, 0, sizeof(resp));
+resp.hdr.type = VIRTIO_GPU_RESP_OK_MAP_INFO;
+virgl_renderer_resource_get_map_info(mblob.resource_id, _info);
+virtio_gpu_ctrl_response(g, cmd, , sizeof(resp));
+}
+
+int
