linux-kernel - Re: [PATCH V4 0/2] Add virtual hardware module

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: <20210407101258.72261c5d@eldfell>
Date:   Wed, 7 Apr 2021 10:12:58 +0300
From:   Pekka Paalanen <ppaalanen@...il.com>
To:     Sumera Priyadarsini <sylphrenadin@...il.com>
Cc:     melissa.srw@...il.com, hamohammed.sa@...il.com,
        rodrigosiqueiramelo@...il.com, airlied@...ux.ie,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH V4 0/2] Add virtual hardware module

On Mon, 5 Apr 2021 11:41:50 +0530
Sumera Priyadarsini <sylphrenadin@...il.com> wrote:

> This patchset adds support for emulating virtual hardware with VKMS.
> The virtual hardware mode can be enabled by using the following command
> while loading the module:
>         sudo modprobe vkms enable_virtual_hw=1

Hi,

every time I see this cover letter subject, I start wondering "what is
this virtual hardware module, yet another one?" and then I read the
cover letter and realise it is about adding an option to VKMS.

The next time you revise this series, could you perhaps clarify the
subject?

The idea of having a mode where VKMS behaves like a virtual hardware
driver is good, IMO. I do think "vblank-less mode" describes it better
though, because I would assume things like USB display drivers to work
like this too, and VKMS is already a virtual driver anyway.

To clarify, as a userspace programmer what I would expect "vblank-less
mode" to be is that the DRM driver completes pageflips and modesets at
arbitrary times, perhaps always immediately or perhaps with a variable
delay that depends on how much processing is needed for the update.
Also vblank events do not fire and vblank counters do not advance. Is
this correct?


Thanks,
pq

> 
> The first patch is prep work for adding virtual_hw mode and refactors
> the plane composition in vkms by adding a helper function vkms_composer_common()
> which can be used for both vblank mode and virtual mode.
> 
> The second patch adds virtual hardware support as a module option. It
> adds new atomic helper functions for the virtual mode
> and modifies the existing atomic helpers for usage by the vblank mode
> This gives us two sets of drm_crtc_helper_funcs struct for both modes,
> making the code flow cleaner and easier to debug.
> 
> This patchset has been tested with the igt tests- kms_writeback, kms_atomic,
> kms_lease, kms_flip, kms_pipe_get_crc and preserves results except for
> subtests related to crc reads and skips tests that rely on vertical
> blanking. This patchset must be tested after incorporating the
> igt-tests patch: https://lists.freedesktop.org/archives/igt-dev/2021-February/029355.html
> 
> Sumera Priyadarsini (2):
>   drm/vkms: Refactor vkms_composer_worker() to prep for virtual_hw mode
>   drm/vkms: Add support for virtual hardware mode
> 
>  drivers/gpu/drm/vkms/vkms_composer.c | 88 +++++++++++++++++-----------
>  drivers/gpu/drm/vkms/vkms_crtc.c     | 51 +++++++++++-----
>  drivers/gpu/drm/vkms/vkms_drv.c      | 18 ++++--
>  drivers/gpu/drm/vkms/vkms_drv.h      |  4 ++
>  4 files changed, 109 insertions(+), 52 deletions(-)
> 


Content of type "application/pgp-signature" skipped