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 <[email protected]>
---
arch/arm64/kernel/efi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index d0cf596..8ff557a 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -55,6 +55,7 @@ static __init pteval_t create_mapping_protection(efi_memory_desc_t *md)
/* we will fill this structure from the stub, so don't put it in .bss */
struct screen_info screen_info __section(.data);
+EXPORT_SYMBOL(screen_info);
int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md)
{
--
1.8.3.1
On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <[email protected]> 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 <[email protected]>
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.
Arnd
From: Arnd Bergmann <[email protected]>
>
> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <[email protected]> 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 <[email protected]>
>
> 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?
Michael
On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <[email protected]> wrote:
> From: Arnd Bergmann <[email protected]>
> > On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <[email protected]> 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 <[email protected]>
> >
> > 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.
Arnd
From: Arnd Bergmann <[email protected]> Sent: Wednesday, March 18, 2020 2:27 AM
>
> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <[email protected]> wrote:
> > From: Arnd Bergmann <[email protected]>
> > > On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <[email protected]> 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 <[email protected]>
> > >
> > > 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.
Michael
On 3/20/20 3:16 AM, Michael Kelley wrote:
> From: Arnd Bergmann <[email protected]> Sent: Wednesday, March 18, 2020 2:27 AM
>>
>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <[email protected]> wrote:
>>> From: Arnd Bergmann <[email protected]>
>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <[email protected]> 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 <[email protected]>
>>>>
>>>> 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
>
On 5/13/20 7:56 PM, Nikhil Mahale wrote:
> On 3/20/20 3:16 AM, Michael Kelley wrote:
>> From: Arnd Bergmann <[email protected]> Sent: Wednesday, March 18, 2020 2:27 AM
>>>
>>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <[email protected]> wrote:
>>>> From: Arnd Bergmann <[email protected]>
>>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <[email protected]> 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 <[email protected]>
>>>>>
>>>>> 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.
In addition to this, even if a driver doesn't implement a framebuffer
console, or if it does but has an option to disable it, the driver still
needs to know whether the EFI console is using resources on the GPU so
it can avoid clobbering them. For example screen_info provides information
like offset and size of EFI console, using this information driver can
reserve memory used by console and prevent corruption on it.
I think arm64 should export screen_info.
> Thanks,
> Nikhil Mahale
>
>> Michael
>>
On Mon, 18 May 2020 at 06:25, Nikhil Mahale <[email protected]> wrote:
>
> On 5/13/20 7:56 PM, Nikhil Mahale wrote:
> > On 3/20/20 3:16 AM, Michael Kelley wrote:
> >> From: Arnd Bergmann <[email protected]> Sent: Wednesday, March 18, 2020 2:27 AM
> >>>
> >>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <[email protected]> wrote:
> >>>> From: Arnd Bergmann <[email protected]>
> >>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <[email protected]> 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 <[email protected]>
> >>>>>
> >>>>> 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.
>
> In addition to this, even if a driver doesn't implement a framebuffer
> console, or if it does but has an option to disable it, the driver still
> needs to know whether the EFI console is using resources on the GPU so
> it can avoid clobbering them. For example screen_info provides information
> like offset and size of EFI console, using this information driver can
> reserve memory used by console and prevent corruption on it.
>
> I think arm64 should export screen_info.
>
If there are reasons why KMS or fbdev drivers may need to access the
information in screen_info, it should be exported. I don't think that
is under debate here.
On 5/18/20 6:21 PM, Ard Biesheuvel wrote:
> External email: Use caution opening links or attachments
>
>
> On Mon, 18 May 2020 at 06:25, Nikhil Mahale <[email protected]> wrote:
>>
>> On 5/13/20 7:56 PM, Nikhil Mahale wrote:
>>> On 3/20/20 3:16 AM, Michael Kelley wrote:
>>>> From: Arnd Bergmann <[email protected]> Sent: Wednesday, March 18, 2020 2:27 AM
>>>>>
>>>>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <[email protected]> wrote:
>>>>>> From: Arnd Bergmann <[email protected]>
>>>>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <[email protected]> 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 <[email protected]>
>>>>>>>
>>>>>>> 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.
>>
>> In addition to this, even if a driver doesn't implement a framebuffer
>> console, or if it does but has an option to disable it, the driver still
>> needs to know whether the EFI console is using resources on the GPU so
>> it can avoid clobbering them. For example screen_info provides information
>> like offset and size of EFI console, using this information driver can
>> reserve memory used by console and prevent corruption on it.
>>
>> I think arm64 should export screen_info.
>>
>
> If there are reasons why KMS or fbdev drivers may need to access the
> information in screen_info, it should be exported. I don't think that
> is under debate here.
>
Hi Ard, thanks for your feedback. If my understanding is correct,
you are agree to export screen_info. Can you provide guidance on how can
we proceed here? are you willing to accept this current patch as-is or
would you like me to re-submit the patch with the additional rationale
provided?
Thanks,
Nikhil Mahale
On Fri, 22 May 2020 at 13:15, Nikhil Mahale <[email protected]> wrote:
>
> On 5/18/20 6:21 PM, Ard Biesheuvel wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, 18 May 2020 at 06:25, Nikhil Mahale <[email protected]> wrote:
> >>
> >> On 5/13/20 7:56 PM, Nikhil Mahale wrote:
> >>> On 3/20/20 3:16 AM, Michael Kelley wrote:
> >>>> From: Arnd Bergmann <[email protected]> Sent: Wednesday, March 18, 2020 2:27 AM
> >>>>>
> >>>>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <[email protected]> wrote:
> >>>>>> From: Arnd Bergmann <[email protected]>
> >>>>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <[email protected]> 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 <[email protected]>
> >>>>>>>
> >>>>>>> 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.
> >>
> >> In addition to this, even if a driver doesn't implement a framebuffer
> >> console, or if it does but has an option to disable it, the driver still
> >> needs to know whether the EFI console is using resources on the GPU so
> >> it can avoid clobbering them. For example screen_info provides information
> >> like offset and size of EFI console, using this information driver can
> >> reserve memory used by console and prevent corruption on it.
> >>
> >> I think arm64 should export screen_info.
> >>
> >
> > If there are reasons why KMS or fbdev drivers may need to access the
> > information in screen_info, it should be exported. I don't think that
> > is under debate here.
> >
>
> Hi Ard, thanks for your feedback. If my understanding is correct,
> you are agree to export screen_info. Can you provide guidance on how can
> we proceed here? are you willing to accept this current patch as-is or
> would you like me to re-submit the patch with the additional rationale
> provided?
>
Please (re-)submit it along with the code that actually makes use of it.