linux-kernel - Re: [BUG][v6.9-rc6] Deadlock with: Revert "drm/qxl: simplify qxl_fence

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <obume4wdvgxc3zljnelhpwrg2rouae322nak5jy3s4hsruoddd@stoopms6fo2a>
Date: Tue, 7 May 2024 12:21:50 +0200
From: Gerd Hoffmann <kraxel@...hat.com>
To: Timo Lindfors <timo.lindfors@....fi>
Cc: David Airlie <airlied@...hat.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Maxime Ripard <mripard@...nel.org>, 
	Steven Rostedt <rostedt@...dmis.org>, LKML <linux-kernel@...r.kernel.org>, 
	Alex Constantino <dreaming.about.electric.sheep@...il.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, Daniel Vetter <daniel@...ll.ch>
Subject: Re: [BUG][v6.9-rc6] Deadlock with: Revert "drm/qxl: simplify
 qxl_fence_wait"

On Tue, May 07, 2024 at 09:38:56AM GMT, Timo Lindfors wrote:
> On Tue, 7 May 2024, David Airlie wrote:
> > I expec this will reintroduce the other problems that caused this
> > change in the first place, but I think this should at least bring us
> > back to regression equilibrium. I can't recommend anyone use qxl hw
> > over virtio-gpu hw in their VMs, since virtio-gpu is actually hw
> > designed for virt.

Well, qxl was designed for virt too, but almost two decades ago with 2d
acceleration.  And alot of complexity, trying to move 2d-accel rendering
from the VM guest to the spice client.  That complexity still bites us
today as this issue shows.

With desktop rendering moving to 3d acceleration all that 2d accel stuff
became mostly useless though, so you have the downsides of the
complexity without any upsides.

There have been plans to add 3d-acceleration support to qxl, but they
never took off and with virtio-gpu having taken that role meanwhile the
idea is dead now.

I second the recommendation to avoid qxl.

> I would love to switch to virtio. It works ok for local virtual machines but
> I have many users who are using Linux desktops hosted on a powerful server
> where it is more difficult. With spice and qxl scrolling in a web browser is
> smooth, with spice and virtio it seems like larger parts are getting fully
> redrawn (and resent over network?).

Hmm, I'd expect behavior being quite simliar for stdvga, qxl and
virtio-gpu when running a wayland desktop remotely.

When running on X11 without 3d acceleration it could be that scroll
ops are actually sent as 2d accel blits on qxl, explaining the
difference you are seeing.

> Now that new gnome is going to come with RDP support I'm also
> considering switching to that. Any tips would be appreciated.

Worth trying: use vnc.  The qemu vnc server will skip updates when the
network pipeline is full.  That throttles the frame rate, but also
reduces the display update latency.

In general the trend seems to be to move to in-guest remote desktop
solutions.  Do NOT make VMs a special case with a special solution,
instead handle VMs like bare metal.  Commercial solutions exist for a
while, some of them are doing hardware-assisted video encoding to send
the display as video stream to the remote end.  gnome+rdp is a new
player here, clearly worth a try.

take care,
  Gerd