Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

Ard Biesheuvel
2016-04-29T20:26:05Z

> On 29 apr. 2016, at 22:06, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
>> On Fri, Apr 29, 2016 at 03:51:49PM +0200, Ard Biesheuvel wrote:
>>> On 29 April 2016 at 15:41, Bjorn Helgaas <helgaas@kernel.org> wrote:
>>>> On Thu, Apr 28, 2016 at 11:39:35PM +0200, Alexander Graf wrote:
>>>> On 28.04.16 20:06, Bjorn Helgaas wrote:
>
>>>>> If firmware is giving us a bare address of something, that seems like
>>>>> a clue that it might depend on that address staying the same.
>>>>
>>>> Well, I'd look at it from the other side. It gives us a correct address
>>>> on entry with the system configured at exactly the state it's in on
>>>> entry. If Linux changes the system, some guarantees obviously don't work
>>>> anymore.
>>>
>>> Can you point me to the part of the EFI spec that communicates this?
>>> I'm curious what the intent is and whether there's any indication that
>>> EFI expects the OS to preserve some configuration. I don't think it's
>>> reasonable for the OS to preserve this sort of configuration because
>>> it limits how well we can support hotplug.
>>>
>>> I wonder if we're using this frame buffer address as more than what
>>> EFI intended. For example, maybe it was intended for use by an early
>>> console driver, but there's some other mechanism we should be using
>>> after that.
>>
>> The UEFI spec describes this as follows (UEFIv2.6 section 11.9)
>>
>> """
>> Graphics output may also be required as part of the startup of an
>> operating system. There are
>> potentially times in modern operating systems prior to the loading of
>> a high performance OS
>> graphics driver where access to graphics output device is required.
>> The Graphics Output Protocol
>> supports this capability by providing the EFI OS loader access to a
>> hardware frame buffer and
>> enough information to allow the OS to draw directly to the graphics
>> output device.
>> """
>>
>> So the intent is to provide minimal framebuffer services until the
>> 'real' driver takes over.
>
> Makes sense. A 'real' driver for a PCI device would use
> pci_register_driver() and use pci_resource_start() or similar to
> locate the framebuffer, which would avoid the problem because the PCI
> core doesn't change BARs while a driver owns the device.
>
>> The GOP protocol only describes the base and size of the framebuffer,
>> and the pixel format. At boot time, the early UEFI code in the kernel
>> could potentially figure out which PCI device it is related to, if
>> necessary, but i am not sure if this would solve the x86 case as well.
>
> Does drivers/video/fbdev/efifb.c support only a single framebuffer
> device? If a system has several, how does it decide which to use? I
> assume UEFI would provide GOP for all the framebuffers?
>

Yes. The early efi code iterates over all gop instances to figure out which one is connected to the efi console.

> If we could fix this by making efifb claim a PCI device, I think that
> would be cleaner. I don't know how to figure out the correct device,
> but that would solve the "BAR changed" problem, and it would have
> cleaner ownership semantics, too.

If the bus layout is static, the efi init code can record the segment/bus/device and match it with the kernel's view. is that guaranteed to be sufficient for all implementations of pci?

> It looks like the current situation is that a device-specific driver
> (radeon, i915, etc.) could claim the device via the usual
> pci_register_driver() path, and the efifb driver could think it owns
> the device at the same time. This seems like too obvious a problem,
> so maybe there's some ad hoc mechanism that resolves this?