Hi Alex, Eric,
> > > Recent updates in OVMF and Seabios have resulted in MMIO regions
> > > being placed at the upper end of the physical address space. As a
> > > result, when a Host device is assigned to the Guest via VFIO, the
> > > following mapping failures occur when VFIO tries to map the M
explain? For qemu it should make a difference what spice-server
> does with the dma-bufs passed (local display / encode video + send to
> remote).
[Kasireddy, Vivek] I agree that Qemu shouldn't care what the spice-server does
with the dmabuf fds but somehow a drawable has to be crea
Hi Frediano, Gerd,
>
> Il giorno mar 24 gen 2023 alle ore 06:41 Kasireddy, Vivek
> ha scritto:
> >
> > + Frediano
> >
> > Hi Gerd,
> >
> > >
> > > Hi,
> > >
> > > > Here is the flow of things from the Qemu
wh = gdk_window_get_height(window);
> -ws = gdk_window_get_scale_factor(window);
> +ww = gtk_widget_get_allocated_width(widget);
> +wh = gtk_widget_get_allocated_height(widget);
[Kasireddy, Vivek] Could you please confirm if this works in X-based compositor
environments as we
et,
> >> GdkEventMotion *motion,
> >> fbw = surface_width(vc->gfx.ds) * vc->gfx.scale_x;
> >> fbh = surface_height(vc->gfx.ds) * vc->gfx.scale_y;
> >>
> >> -window = gtk_widget_get_window(vc->gfx.drawing_area);
> >> -ww = g
Hi Antonio,
>
> I am starting to believe that the error is due to the fact that no EGLContext
> is active on the
> current thread (the one running the Vulkan application).
[Kasireddy, Vivek] Which UI module (and Host environment) are you testing with?
gtk? egl-headless? Could you pl
.
> >
> >> Because of all of the above, I don't think it makes sense to
> >> hard-require udmabuf at the start of Qemu. It's much better to fail
> >> resource creation dynamically.
> >
> > Disagree. When virgl/venus is enabled, then yes, qemu w
Hi Marc-Andre,
>
> Hi
>
> On Sat, Jan 20, 2024 at 4:54 AM Vivek Kasireddy
> wrote:
> >
> > Since most encoders (invoked by Spice) may not work with tiled memory
> > associated with a texture, we need to create another texture that has
> > linear memory layout and use that instead.
> >
> > Note
Hi Marc-Andre,
>
> Hi
>
> On Sat, Jan 20, 2024 at 4:54 AM Vivek Kasireddy
> wrote:
> >
> > Newer versions of Spice server should be able to accept dmabuf
> > fds from Qemu for clients that are connected via the network.
> > In other words, when this option is enabled, Qemu would share
> > a dma
Hi Marc-Andre,
>
> Hi
>
> On Sat, Jan 20, 2024 at 4:54 AM Vivek Kasireddy
> wrote:
> >
> > In the specific case where the display layer (virtio-gpu) is using
> > dmabuf, and if remote clients are enabled (-spice gl=on,port=),
> > it makes sense to limit the maximum (streaming) rate to 60 FP
Hi Marc-Andre,
>
> Hi
>
> On Sat, Jan 20, 2024 at 4:54 AM Vivek Kasireddy
> wrote:
> >
> > Giving users an option to choose a particular codec will enable
> > them to make an appropriate decision based on their hardware and
> > use-case.
> >
> > Cc: Gerd Hoffmann
> > Cc: Marc-André Lureau
> >
base
> >
> > Fixes: 7cc712e9862ff ("ui: dispatch GL events to all listeners")
>
> I am not able to reproduce on current master.
[Kasireddy, Vivek] I can still see it with current master. I think this issue
is only seen when running Qemu in an Xorg based Host environment
Hi Marc-Andre,
>
> Hi
>
> On Mon, Mar 7, 2022 at 10:00 PM Kasireddy, Vivek
> wrote:
> >
> > Hi Marc-Andre,
> >
> > >
> > > Hi Vivek
> > >
> > > On Mon, Mar 7, 2022 at 8:39 AM Vivek Kasireddy
> > > wrote:
> > &
Hi Markus,
> Any overlap with Dongwon Kim's "[PATCH v5 0/2] handling guest multiple
> displays"?
[Kasireddy, Vivek] Yes, there is some overlap but as I mentioned in the cover
letter,
this series is intended to replace Dongwon's series dealing with multiple
mapping exists for a VC, it will be
> > +# fullscreened on that specific monitor or else it would not
> > be
> > +# displayed anywhere and would appear disconnected to the
> > guest.
>
> Let's see whether I understand this... We have
Hi Mike,
Sorry for the late reply; I just got back from vacation.
If it is unsafe to directly use the subpages of a hugetlb page, then reverting
this patch seems like the only option for addressing this issue immediately.
So, this patch is
Acked-by: Vivek Kasireddy
As far as the use-case is conc
Hi David,
>
> On 12.06.23 09:10, Kasireddy, Vivek wrote:
> > Hi Mike,
>
> Hi Vivek,
>
> >
> > Sorry for the late reply; I just got back from vacation.
> > If it is unsafe to directly use the subpages of a hugetlb page, then
> > reverting
Hi David,
>
> On 13.06.23 10:26, Kasireddy, Vivek wrote:
> > Hi David,
> >
> >>
> >> On 12.06.23 09:10, Kasireddy, Vivek wrote:
> >>> Hi Mike,
> >>
> >> Hi Vivek,
> >>
> >>>
> >>> Sorry for the
Hi,
>
> On Thu, Dec 14, 2023 at 8:26 AM Dongwon Kim
> wrote:
> >
> > If the guest state is paused before it gets a response for the current
> > scanout frame submission (resource-flush), it won't flush new frames
> > after being restored as it still waits for the old response, which is
> > accep
Hi Laszlo,
>
> On 11/13/23 08:32, Vivek Kasireddy wrote:
> > A recent OVMF update has resulted in MMIO regions being placed at
> > the upper end of the physical address space. As a result, when a
> > Host device is passthrough'd to the Guest via VFIO, the following
> > mapping failures occur when
Hi Gerd,
> > -pixman_image_unref(res->image);
> > +if (res->image) {
> > +pixman_image_unref(res->image);
> > +}
>
> There is qemu_pixman_image_unref().
>
> Like pixman_image_unref except that it also accepts (and ignores) NULL
&
GTK UI from 3.22 to 4.x
3) Add explicit sync support to GTK4 and Qemu UI
4) Add support for VIRTGPU_BLOB_MEM_HOST3D
We'll start sending patches as we go along.
Thanks,
Vivek
> > [Kasireddy, Vivek] Sure, we'll take a look at your work and use that
> > as a starting point
the new virgl device, same as
> > > virtio-gpu-device,virgl=on today.
> > >
> > > When compiling qemu without virglrenderer support virtio-gpu-device
> > > behavior doesn't change.
[Kasireddy, Vivek] Just a random thought: if a user enable
> -Original Message-
> From: Kasireddy, Vivek
> Sent: Tuesday, March 30, 2021 8:10 PM
> To: qemu-devel@nongnu.org
> Cc: Kasireddy, Vivek ; Gerd Hoffmann
> ; Marc-André Lureau ; Kim,
> Dongwon ; Zhang, Tina
> Subject: [PATCH 00/11] Add support for Blob resources feature
>
&g
Hi Gerd,
>
> > Any other ideas as to how to eliminate that Blit cleanly?
>
> Well, "cleanly" pretty much implies "supported by toolkit".
[Kasireddy, Vivek] I was kind of hoping you'd not draw that implication :)
>
> gtk glarea for example set
final revision of the
> blob resource
> specification. I wouldn't be able to update this in near future due to being
> busy with other
> projects. Feel free to grab & update & submit these patches though.
[Kasireddy, Vivek] Sure, we'll take a look at your work and
; > +return NULL
> > +}
>
> Fails to build for !linux ...
>
> You can place the stubs in a file in the stubs/ directory instead.
> They'll be used via weak symbol references instead of #ifdefs then.
>
> Advantage: the stubs are compiled unconditionally so e
Hi Gerd,
> Hi,
>
> > +#ifdef CONFIG_LINUX
>
> Seems wee need "#if defined(CONFIG_LINUX) && defined(F_GET_SEALS)" here
> to cover old linux versions. I see some build failures in gitlab CI due to
> F_GET_SEALS not being defined (crypto-old-nettle for
data such as modifier, format, etc.
>
> That is pretty much mandatory. Without blob resources there is no concept of
> resources
> shared between host and guest in virtio-gpu, all data is explicitly copied
> with transfer
> commands.
[Kasireddy, Vivek] My understanding of virt
Hi Marc-Andre,
+create = g_malloc0(sizeof(*create) +
+ res->iov_cnt * sizeof (struct udmabuf_create_item));
+if (!create)
+return NULL;
Pointless allocation check (g_malloc will abort if it failed to allocate)
[Kasireddy, Vivek] Ok, will remove it in
ommits/virtio-gpu-next
>
> Doesn't apply cleanly to master, can you rebase and resend?
[Kasireddy, Vivek] Sure, just sent a v5.
Thanks,
Vivek
>
> thanks,
> Gerd
gt; +return NULL
> > +}
>
> Fails to build for !linux ...
>
> You can place the stubs in a file in the stubs/ directory instead.
> They'll be used via weak symbol references instead of #ifdefs then.
[Kasireddy, Vivek] Will do; should I send the whole series (v6) again wi
ould allow to decouple user
> interface code
> from qemu without making compromises on performance, which is probably quite
> useful
> for a number of use cases, like a zero-copy wayland client, or a client using
> drm directly.
[Kasireddy, Vivek] We considered having a separate cl
leftovers
> from udmabuf prototype which didn't use blob resources). I think it would be
> useful to
> merge patch #2 with this one.
[Kasireddy, Vivek] Ok, will do.
>
> Also we might cleanup things a bit. Do we need separate remapsz + blob_size
> fields in the
> first
Reviewed-by: Vivek Kasireddy
> -Original Message-
> From: Qemu-devel On
> Behalf Of Dongwon Kim
> Sent: Friday, July 02, 2021 5:28 PM
> To: qemu-devel@nongnu.org
> Cc: Kim, Dongwon
> Subject: [PATCH 3/3] ui/gtk: gd_draw_event returns FALSE when no cairo
> surface is
> bound
>
> gd_dr
Reviewed-by: Vivek Kasireddy
> -Original Message-
> From: Qemu-devel On
> Behalf Of Dongwon Kim
> Sent: Friday, July 02, 2021 5:28 PM
> To: qemu-devel@nongnu.org
> Cc: Romli, Khairul Anuar ; Kim, Dongwon
>
> Subject: [PATCH 1/3] ui/gtk-egl: un-tab and re-tab should destroy egl surface
Acknowledged-by: Vivek Kasireddy
> -Original Message-
> From: Qemu-devel On
> Behalf Of Dongwon Kim
> Sent: Friday, July 02, 2021 5:28 PM
> To: qemu-devel@nongnu.org
> Cc: Kim, Dongwon
> Subject: [PATCH 2/3] ui/gtk-egl: make sure the right context is set as the
> current
>
> Making t
rface_gl_destroy_texture(vc->gfx.gls, vc->gfx.ds);
> surface_gl_create_texture(vc->gfx.gls, vc->gfx.ds);
> }
> +if (vc->gfx.guest_fb.dmabuf) {
> +vc->gfx.guest_fb.dmabuf->texture = 0;
[Kasireddy
de;
> + dmabuf->buf.x = r->x;
> +dmabuf->buf.y = r->y;
> +dmabuf->buf.scanout_width;
> +dmabuf->buf.scanout_height;
[Kasireddy, Vivek] Would you not be able to use buf.width and buf.height?
What is the difference between these and scanout_width/height?
| 2 +-
> 6 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/hw/display/virtio-gpu-udmabuf.c b/hw/display/virtio-gpu-udmabuf.c
[Kasireddy, Vivek] You might not want to mix virtio-gpu and UI changes in the
same patch.
> index a64194c6de..3ea6e76371 100644
> --
u
> > BLOB API (thanks!) and have identified a few holes that are still needed for
> > Vulkan support.
> >
> > We would like to know if anybody else is working on Vulkan support or on
> > common tasks such as host-side blobs, CONTEXT_INIT, CROSS_DEVICE,
> > HOST_VISI
Reviewed-by: Vivek Kasireddy
> -Original Message-
> From: Qemu-devel On
> Behalf Of Gerd Hoffmann
> Sent: Friday, June 04, 2021 12:50 AM
> To: qemu-devel@nongnu.org
> Cc: Alexander Bulekov ; Gerd Hoffmann ;
> Michael S. Tsirkin
> Subject: [PATCH] virtio-gpu: move scanout_id sanity chec
Hi Gerd,
> > +epoxy_has_egl_extension(qemu_egl_display,
> > +"EGL_ANDROID_native_fence_sync")) {
>
> What about non-android? Is the name there just for historical reasons?
> Or do we actually need something else for desktop
Hi Philippe,
I am really sorry for the late review; I totally missed it until now.
Please find my comments inline.
From: Marc-André Lureau
Sent: Wednesday, July 07, 2021 4:05 AM
To: Philippe Mathieu-Daudé ; Kasireddy, Vivek
Cc: QEMU ; Gerd Hoffmann ; Michael S.
Tsirkin
Subject: Re: [RFC
t;sync);
> > +eglDestroySyncKHR(qemu_egl_display, dmabuf->sync);
> > +dmabuf->sync = NULL;
> > +}
> > +}
>
> > +void egl_dmabuf_wait_sync(QemuDmaBuf *dmabuf)
> > +{
>
> Hmm, still the blocking wait. Can't you do something like
[Kasire
}
> }
>
> Then, when resuming processing after unblock check pending_completion
> and call virtio_gpu_ctrl_response_nodata if needed.
>
> Workflow:
>
> virtio_gpu_simple_process_cmd()
> -> virtio_gpu_resource_flush()
> -> dpy_gfx_update()
> -
Hi Gerd,
> Hi,
>
> > dmabuf->buf.fd = res->dmabuf_fd;
> > +dmabuf->buf.blob = true;
>
> Do you actually need the 'blob' field?
> I think checking 'fd' instead should work too.
[Kasireddy, Vivek] I want these changes to be l
function 'gd_egl_scanout_flush':
> > ../../ui/gtk-egl.c:301:9: error: implicit declaration of function
> > 'egl_dmabuf_create_sync' [-Werror=implicit-function-declaration]
> > 301 | egl_dmabuf_create_sync(vc->gfx.guest_fb.dmabuf);
> > | ^~
> > ../../ui/gtk-egl.c:301:9: error: nested extern declaration of
> > 'egl_dmabuf_create_sync' [-Werror=nested-externs]
> >
> >
> > You can probably repro this on any system which has the opengl
> > libraries installed but not libgbm.
>
> Vivek? Can you have a look please?
[Kasireddy, Vivek] I sent a v6 that fixes these compilation errors:
https://lists.nongnu.org/archive/html/qemu-devel/2021-09/msg03859.html
Compile tested the patches with and without GBM.
Thanks,
Vivek
gt; > +if wayland.found()
> > + wayland_ss = ss.source_set()
> > + wayland_ss.add(when: wayland, if_true: files('wayland.c',
> > +'xdg-shell-protocol.c',
> > +'fullscreen-shell-unstable-v1-protocol.c','linux-dmabuf-unstable-v1-p
> >
; and virtio-gpu would benefit from this work.
>
> IME, QEMU already suffers from having too many barely maintained UI
> implementations and iti s confusing to users. Using a toolkit like GTK
> is generally a good thing, even if they don't enable the maximum
> theoretical performance,
e Blit can be eliminated
> > by sharing the dmabuf fd -- associated with the Guest scanout buffer --
> > directly with the Host compositor via the linux-dmabuf (unstable) protocol.
>
> Hmm, that probably means no window decorations (and other UI elements),
[Kasireddy, Vivek] Right,
Hi Gerd,
> > >
> > > > dmabuf->buf.fd = res->dmabuf_fd;
> > > > +dmabuf->buf.blob = true;
> > >
> > > Do you actually need the 'blob' field?
> > > I think checking 'fd' instead should work too.
>
Hi Dmitry,
> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
>
> On 2/6/25 01:13, Dmitry Osipenko wrote:
> > On 2/5/25 23:08, Dmitry Osipenko wrote:
> >>> Thanks for showing me the video. I will take a look and check what would
> go wrong here. I kinda understand corruption ma
Hi Dmitry,
> Subject: Re: [PATCH v2 4/6] ui/console-gl: Add a helper to create a texture
> with linear memory layout
>
> On 3/26/25 02:39, Vivek Kasireddy wrote:
> > +void surface_gl_create_texture_from_fd(DisplaySurface *surface,
> > + int fd, GLuint *textur
54 matches
Mail list logo
