<div dir="ltr">Another Kconfig option? How many people will really understand what it means and whether to use it?<div><br></div><div>Has just reserving 2 GiB as a hard and fast rule hurt anyone yet? </div><div><br></div><div>thanks</div><div><br></div><div>ron</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 3, 2016 at 11:25 PM Patrick Rudolph <<a href="mailto:siro@das-labor.org">siro@das-labor.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016-06-03 05:41 PM, Aaron Durbin via coreboot wrote:<br>
> On Fri, Jun 3, 2016 at 7:04 AM, Patrick Rudolph <<a href="mailto:siro@das-labor.org" target="_blank">siro@das-labor.org</a>> wrote:<br>
>> Hello,<br>
>> I want to start a discussion about PCI MMIO size that hit me a couple of<br>
>> times using coreboot.<br>
>> I'm focused on Intel Sandybridge, but I guess this topic applies to all<br>
>> x86 systems.<br>
>><br>
>> On most Intel systems the PCI mmio size is hard-coded in coreboot to<br>
>> 1024Mbyte, but the value is hidden deep inside raminit code.<br>
>> The mmio size for dynamic resources is limited on top by PCIEXBAR,<br>
>> IOAPIC, ME stolen, ... that takes 128Mbyte and on the other end it's<br>
>> limited by graphics stolen and TSEG that require at least 40Mbyte.<br>
>> In total there's only space for two 256Mbyte PCI BARs, due to alignment.<br>
>> That's enough for systems that only do have an Intel GPU, but it fails<br>
>> as soon as PCI devices use more than a single 256Mbyte BAR.<br>
>> The PCI mmio size is set in romstage, but PCI BARs are configured in<br>
>> ramstage.<br>
>><br>
>> Following questions came to my mind:<br>
>> * How does the MRC handle this ?<br>
>> * Should the user be able to modify PCI mmio size ?<br>
>> * How to pass the required PCI mmio size to romstage ?<br>
>>   A good place seems to be the mrc cache, but ramstage doesn't know<br>
>> about it's structure.<br>
>> * How is this solved on AMD systems ?<br>
>> * Should the romstage scan PCI devices and count required BAR size ?<br>
><br>
> In the past (not sure if it's still true), Intel UEFI systems do a<br>
> reboot after calculating the MMIO space requirements so that the<br>
> memory init code knows how much to allocate for MMIO resource<br>
> allocation. I always found that distasteful and I have always used a<br>
> 2GiB I/O hole ever since. I never cared about 32-bit kernels so I<br>
> always found that to be a decent tradeoff. It also makes MTRR and<br>
> address space easy to digest when looking at things.<br>
><br>
<br>
I like the idea of a reboot. It only has to be done after hardware<br>
changes that affect the PCI mmio size.<br>
With mrc cache in place it shouldn't be notable at all.<br>
<br>
On the other hand, hard-coding the limit is much simpler.<br>
What do you think about a Kconfig option<br>
"Optimize PCI mmio size for x86_64 OS" ?<br>
<br>
It would increase the size to 2GiB. Of course it would work on i386, but<br>
you might see less usable<br>
DRAM than before.<br>
<br>
>><br>
>> Regards,<br>
>> Patrick<br>
>><br>
>> --<br>
>> coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
>> <a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/mailman/listinfo/coreboot</a><br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote></div>