On Fri, Apr 29, 2016 at 10:25:13PM +0200, Ard Biesheuvel wrote: > > > On 29 apr. 2016, at 22:06, Bjorn Helgaas <helg...@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 <helg...@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?
In theory, no. The kernel can reassign bus numbers to make space for hotplug devices. In practice, they're like BARs: if the firmware sets them up, we don't normally change them unless they're obviously broken.
