linux-kernel - Re: RE: [PATCH v6 09/10] arm64: efi: Export screen

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]

Date:   Wed, 13 May 2020 19:56:14 +0530
From:   Nikhil Mahale <nmahale@...dia.com>
To:     Michael Kelley <mikelley@...rosoft.com>,
        Arnd Bergmann <arnd@...db.de>
CC:     Will Deacon <will@...nel.org>, Ard Biesheuvel <ardb@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Mark Rutland <mark.rutland@....com>,
        Marc Zyngier <maz@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        gregkh <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        "olaf@...fle.de" <olaf@...fle.de>,
        Andy Whitcroft <apw@...onical.com>,
        vkuznets <vkuznets@...hat.com>, Jason Wang <jasowang@...hat.com>,
        "marcelo.cerri@...onical.com" <marcelo.cerri@...onical.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Sunil Muthuswamy <sunilmut@...rosoft.com>,
        Boqun Feng <boqun.feng@...il.com>
Subject: Re: RE: [PATCH v6 09/10] arm64: efi: Export screen_info

On 3/20/20 3:16 AM, Michael Kelley wrote:
> From: Arnd Bergmann <arnd@...db.de> Sent: Wednesday, March 18, 2020 2:27 AM
>>
>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <mikelley@...rosoft.com> wrote:
>>> From: Arnd Bergmann <arnd@...db.de>
>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@...rosoft.com> wrote:
>>>>>
>>>>> The Hyper-V frame buffer driver may be built as a module, and
>>>>> it needs access to screen_info. So export screen_info.
>>>>>
>>>>> Signed-off-by: Michael Kelley <mikelley@...rosoft.com>
>>>>
>>>> Is there any chance of using a more modern KMS based driver for the screen
>>>> than the old fbdev subsystem? I had hoped to one day completely remove
>>>> support for the old CONFIG_VIDEO_FBDEV and screen_info from modern
>>>> architectures.
>>>>
>>>
>>> The current hyperv_fb.c driver is all we have today for the synthetic Hyper-V
>>> frame buffer device.  That driver builds and runs on both ARM64 and x86.
>>>
>>> I'm not knowledgeable about video/graphics drivers, but when you
>>> say "a more modern KMS based driver", are you meaning one based on
>>> DRM & KMS?  Does DRM make sense for a "dumb" frame buffer device?
>>> Are there any drivers that would be a good pattern to look at?
>>
>> It used to be a lot harder to write a DRM driver compared to an fbdev
>> driver, but this has changed to the opposite over the years.
>>
>> A fairly minimal example would be drivers/gpu/drm/pl111/pl111_drv.c
>> or anything in drivers/gpu/drm/tiny/, but you may want to look at the
>> other hypervisor platforms first, i.e drivers/gpu/drm/virtio/virtgpu_drv.c,
>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c, drivers/gpu/drm/xen/xen_drm_front.c,
>> drivers/gpu/drm/qxl/qxl_drv.c, and drivers/gpu/drm/bochs/bochs_drv.c.
>>
> 
> Thanks for the pointers, especially for the other hypervisors.
> 
Sorry if anybody in 'to' or 'cc' is receiving this reply multiple times.
I had configured by email client incorrectly to reply.

screen_info is still useful with a modern KMS-based driver.  It exposes
the mode parameters that the GOP driver chose.  This information is
needed to implement seamless or glitchless boot, by both ensuring that
the scanout parameters don't change and being able to read back the
scanout image to populate the initial contents of the new surface.

This works today on arches which implement (U)EFI and export
screen_info, including x86 and powerpc, but doesn't work on arm or
arm64.  As arm64 systems that implement UEFI with real GOP drivers
become more prevalent, it would be nice to be have these features there
as well.

Thanks,
Nikhil Mahale

> Michael
>