[coreboot] [patch 16/16] Ranges unavailable for PCI BARs shouldbemarked as reserved in the E820 memory map, in case the OS wants to change the BARs.

[Scott Duplichan]

-----Original Message-----
From: Rudolf Marek [mailto:r.marek at assembler.cz] 
Sent: Sunday, November 07, 2010 03:15 PM
To: Scott Duplichan
Cc: 'Tobias Diedrich'; coreboot at coreboot.org
Subject: Re: [coreboot] [patch 16/16] Ranges unavailable for PCI BARs shouldbemarked as reserved in the E820 memory map,in case the
OS wants to change the BARs.

]Hi,
]
]I thought our resource allocator did not touch the high region because of 
]lapic/hpet/apic stuff. Maybe it is no longer true. I got some issue with PCI 
]sata  add on card (linux complaining about resource overlap on SB700)

Hello Rudolf,

You are right about coreboot, at least for the present time. However,
the allocation scheme still needs some work. For example, fec00000
and above is never allocated to a pci device because of the I/O apic,
which is on the pci bus. However, mmconf is not protected from pci use,
because it falls under 'APIC_CLUSTER: 0', and not a pci bus:
http://www.coreboot.org/pipermail/coreboot/2010-October/061320.html

I think the immediate concern for reserving flash memory space is
because the OS is allowed to make PCI resource assignments on its own.
The OS could use any range not reserved in e820. However, windows,
and possibly linux, also restrict PCI use to address ranges that ACPI
_CRS show as belonging to the pci bus. Coreboot still needs work in
this area. So maybe my example is a little far-fetched. But a commercial
BIOS reserves all the memory decoded by the flash chip, so coreboot
should probably do the same unless there is a specific reason not to.

]Maybe this is heading to same direction?

Could be. I have two overlap situations with win7 to avoid. One is the
mmconf problem described above. The other is when two video cards are
present, they both claim the legacy vga memory and I/O ranges.

]Thanks,
]Rudolf