Attention is currently required from: Marc Jones, Nico Huber, Jonathan Zhang, Philipp Deppenwiese, Tim Wawrzynczak, Julius Werner, Angel Pons, Subrata Banik, Patrick Rudolph, Peter Tsung Ho Wu, Ron Minnich. Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/52585 )
Change subject: lib: set up specific purpose memory as LB_MEM_SOFT_RESERVED ......................................................................
Patch Set 3:
(2 comments)
Commit Message:
https://review.coreboot.org/c/coreboot/+/52585/comment/fe678c07_22bc15da PS3, Line 27: [1] [2]
File src/include/device/device.h:
https://review.coreboot.org/c/coreboot/+/52585/comment/1a699ef6_87cd1bb1 PS3, Line 286: fixed_mem_resource(dev, idx, basek, sizek, IORESOURCE_CACHEABLE \ I don't think we want to mark this cacheable. It'll contribute to the MTRR solution when I think we should be allowing the OS to decide how to set up caching. Presumably we are reserving this for the drivers to pick up and do what is necessary.
We might even need to omit this part of the address space entirely w.r.t. MTRR calculations.
What does the MTRR solution look like when you're booting like this? I'd also be curious to know MTRR solution and if the kernel complains when the following patch is provided:
$ git diff diff --git a/src/cpu/x86/mtrr/mtrr.c b/src/cpu/x86/mtrr/mtrr.c index cb7ecdc963..7e31921ebf 100644 --- a/src/cpu/x86/mtrr/mtrr.c +++ b/src/cpu/x86/mtrr/mtrr.c @@ -184,7 +184,7 @@ static struct memranges *get_physical_address_space(void) /* Collect cacheable and uncacheable address ranges. The * uncacheable regions take precedence over the cacheable * regions. */ - memranges_init(addr_space, mask, mask, MTRR_TYPE_WRBACK); + memranges_init(addr_space, mask | IORESOURCE_SOFT_RESERVE, mask, MTRR_TYPE_WRBACK); memranges_add_resources(addr_space, mask, 0, MTRR_TYPE_UNCACHEABLE);