Re: [PATCH] drm/hyperv: add a parameter to disable the vblank timer

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 19.10.26 um 20:38 schrieb Hamza Mahfooz:
> On Mon, Oct 19, 2026 at 06:03:55PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 19.10.26 um 17:40 schrieb Lanfeng Wei:
>>> Hi Thomas,
>>>
>>>> Yeah, what's the cause of it? Switching off features does not fix any
>>>> bugs or improve the status quo.
>>> You are right that the module parameter is only a workaround for users
>>> affected; it does not fix the underlying scheduling problem.
>>>
>>> The cause is that the synthetic vblank timer is used to pace completion
>>> of atomic updates triggered by dirtyfb, in addition to providing
>>> synthetic vblank events. In Xorg's software-cursor path, pointer motion
>>> damages the primary framebuffer and the damage is instantly submitted
>>> via DRM_IOCTL_MODE_DIRTYFB. The Hyper-V dirtyfb path performs a
>>> synchronous atomic commit, and with the vblank timer enabled that commit
>>> can wait for the next simulated vblank. Under continuous pointer motion,
>>> these commits dominate the update path and delay normal client updates,
>>> resulting in sever frame-rate drops.
>>>
>>> This particular regression results from the combination of the blocking
>>> dirtyfb path, synthetic vblank pacing, and the absence of a Linux DRM
>>> cursor plane in Hyper-V. While the Hyper-V video protocol does have a
>>> hardware-cursor command path, the upstream hyperv_drm driver currently
>>> exposes only a primary plane. Cursor plane support was deferred during
>>> the initial upstreaming [1]. Without a cursor plane, Xorg has to fall
>>> back to software cursor-rendering path and it competes with periodic
>>> graphical updates on the primary plane.
>>>
>>> So the proper long-term fix could be adding cursor plane support in the
>>> Hyper-V DRM driver, which may take some time. Providing that the stated
>>> purpose of the offending commit is to rate-limit display updates, while
>>> its current implementation regresses the existing software-cursor path,
>>> I think adding a switch or reverting the commit until the requested
>>> features in the driver is ready, is a reasonable short-term fix.
>> The problem is that module parameters are impossible to remove in practice.
>> Once in place, someone always depends on it. They also increase the number
>> of states to test.  Avoiding them is usually a good idea. Especially as
>> workarounds for bug or regressions.
>>
>>
>> I'm not familiar with the Hyper-V protocol, so I have a question. Why is it
>> hard to implement cursors? From the link at [1], I assume that cursor
>> support was left out because the simple-kms pipeline did not support cursor
>> planes. This has long been resolved: the simple-kms pipeline is gone and
>> hyperv_drm runs on the regular DRM framework.  Unless there's anything
>> special with the Hyper-V protocol, cursor-plane support should be do-able in
>> a single patch. [^1]
>>
> I actually have been working on cursor plane support for hyperv-drm.
> I'll post a patch soon.

Awesome! Even if it doesn't fix the reported bug, it is still an 
improvement for everyone.

To fix the bug, you *might* have to implement atomic_async_update. [1]  
It allows legacy cursor updates to jump ahead of the commits and change 
the cursor without vblank synchronization. It's a little-used feature 
and semi-deprecated, but maybe necessary in case.  (Make it a separate 
patch, I'd say.)  There's existing support in other drivers to see how 
it works.

[1] 
https://elixir.bootlin.com/linux/v7.3/source/include/drm/drm_modeset_helper_vtables.h#L1406

Best regards
Thomas

>
> Hamza
>
>> Best regards
>> Thomas
>>
>> [^1] See https://elixir.bootlin.com/linux/v7.2.11/source/drivers/gpu/drm/ast/ast_cursor.c
>> for an example of how this looks. Most of it is hardware-related, but hyperv
>> would likely be similar in concept.
>>
>>>> We had another fix for a problem with vblank timers:
>>>>
>>>> https://lore.kernel.org/dri-devel/20260914110004.211027-1-tzimmermann@suse.de/
>>>>
>>>> Did you validate that this fix is unrelated?
>>> Yes I tested that fix and confirmed that it is irrelevant. It solves
>>> issues with excessively long frame durations, however this problem is
>>> found in normal frame updates (in my case 60Hz / 16.7 ms per frame, way
>>> below INT_MAX).
>>>
>>> Best regards,
>>>
>>> Lanfeng Wei
>>>
>>> [1] https://lore.kernel.org/dri-devel/20200622110623.113546-1-drawat.floss@gmail.com/
>> -- 
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
>> GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri, (HRB 36809, AG Nürnberg)
>>
>>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri, (HRB 36809, AG Nürnberg)