Re: Need to reserve Intel graphics memory in early boot

On Tue, Aug 07, 2018 at 09:04:57AM +0100, Johannes Lundberg wrote:
> Hi
> 
> I'm working on getting the graphics drivers up to Linux 4.16 version and
> there has been a patch for Intel gpus that require some code in early boot.
> 
> The problem is that no all bios report the memory allocated for the gpu,
> called stolen memory, correctly so on some configurations the OS can
> reclaim this memory during boot that thus it's not accessible to the gpu
> driver (at least that is my understanding). Drivers need the stolen memory
> for frame buffer compression (fbc) to work (maybe more features as well
> depend on stolen memory). The purpose of fbc is to reduce power consumption.
> 
> So, what we need to do is get the base and size of the stolen memory and
> reserve it before the OS have a chance to claim it. This information will
> be stored in a global variable that the drm i915 driver can later read.
> 
> The Linux implementation can be found here:
> https://elixir.bootlin.com/linux/v4.16/source/arch/x86/kernel/early-quirks.c#L539
> 
> The drm and i915 driver code are dual licensed but I'm not sure about the
> code in the file above, it might be GPL only.
> 
> Anyone feeling up to doing this? Or if you have any pointers as to where
> would be a good place to implement this in FreeBSD, I can give it a shot.

Most likely what you need is to exclude the range from the phys_avail[]
array.  Look at the amd64/machdep.c how this array is handled by early
startup.

Another option might be to not exclude the pages from phys_avail[], but
instead use vm_page_blacklist_add() function to reserve some pages.
The difference with phys_avail[] approach is that blacklist_add can
be done somewhat later, after VM subsystem consumed phys_avail[] and
initialized the structures to describe the page frames.

Depending on the fbc code, it might be more convenient to have vm_page_t
describing the stolen memory, but the drawback is that it can be done
later in boot process, and depending on the location of the stolen mem,
other kernel subsystem might already carved some pages from it.