Hello Aaron Durbin,
I'd like you to do a code review. Please visit
https://review.coreboot.org/c/coreboot/+/34991
to review the following change.
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
arch/x86: Include stack_top region into postcar_frame
This patch signals to the system that stack region also needs to be accounted for as it holds MTRR related values.
Change-Id: I9279bbd66be0ad309bdabbbb90bf59c6f5967c47 Signed-off-by: Aaron Durbin adurbin@chromium.org Signed-off-by: Subrata Banik subrata.banik@intel.com --- M src/arch/x86/include/arch/cpu.h M src/arch/x86/postcar_loader.c 2 files changed, 12 insertions(+), 5 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/91/34991/1
diff --git a/src/arch/x86/include/arch/cpu.h b/src/arch/x86/include/arch/cpu.h index 9aa446e..075e890 100644 --- a/src/arch/x86/include/arch/cpu.h +++ b/src/arch/x86/include/arch/cpu.h @@ -298,6 +298,7 @@ */
struct postcar_frame { + uintptr_t stack_top; uintptr_t stack; uint32_t upper_mask; int max_var_mtrrs; diff --git a/src/arch/x86/postcar_loader.c b/src/arch/x86/postcar_loader.c index b1b2da0..d017260 100644 --- a/src/arch/x86/postcar_loader.c +++ b/src/arch/x86/postcar_loader.c @@ -66,7 +66,10 @@
postcar_frame_prepare(pcf); pcf->stack = (uintptr_t)stack; - pcf->stack += stack_size; + /* Keep track of stack top to calculate size used */ + pcf->stack_top = pcf->stack; + pcf->stack_top += stack_size; + return 0; }
@@ -143,15 +146,18 @@ return (void *) pcf->stack; }
-static void finalize_load(uintptr_t *stack_top_ptr, uintptr_t stack_top) +static void finalize_load(uintptr_t *stack_top_ptr, + const struct postcar_frame *pcf) { - *stack_top_ptr = stack_top; + *stack_top_ptr = pcf->stack; /* * Signal to rest of system that another update was made to the * postcar program prior to running it. */ prog_segment_loaded((uintptr_t)stack_top_ptr, sizeof(uintptr_t), SEG_FINAL); + /* Also signal the stack region that was written as well */ + prog_segment_loaded(pcf->stack, pcf->stack_top - pcf->stack, SEG_FINAL); }
static void load_postcar_cbfs(struct prog *prog, struct postcar_frame *pcf) @@ -173,7 +179,7 @@ die_with_post_code(POST_INVALID_ROM, "No parameters found in after CAR program.\n");
- finalize_load(rsl.params, pcf->stack); + finalize_load(rsl.params, pcf);
stage_cache_add(STAGE_POSTCAR, prog); } @@ -191,7 +197,7 @@ /* This is here to allow platforms to pass different stack parameters between S3 resume and normal boot. On the platforms where the values are the same it's a nop. */ - finalize_load(prog.arg, pcf->stack); + finalize_load(prog.arg, pcf); } else load_postcar_cbfs(&prog, pcf);
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 1:
(1 comment)
I'm not sure we want to go down this route because of how painful all the various corner cases are when wanting WB cache type for increasing loading speed ramstage. microarchitecture details are making consistency hard.
https://review.coreboot.org/c/coreboot/+/34991/1/src/arch/x86/postcar_loader... File src/arch/x86/postcar_loader.c:
https://review.coreboot.org/c/coreboot/+/34991/1/src/arch/x86/postcar_loader... PS1, Line 69: This absolutely needs to stay.
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 1:
(1 comment)
https://review.coreboot.org/c/coreboot/+/34991/1/src/arch/x86/postcar_loader... File src/arch/x86/postcar_loader.c:
https://review.coreboot.org/c/coreboot/+/34991/1/src/arch/x86/postcar_loader... PS1, Line 69:
This absolutely needs to stay.
do you mean pcf->stack and pcf->stack_top should point to same address ?
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 1:
Patch Set 1:
(1 comment)
I'm not sure we want to go down this route because of how painful all the various corner cases are when wanting WB cache type for increasing loading speed ramstage. microarchitecture details are making consistency hard.
no, as we discussed, WB might have hard to track. this is just to conclude the WB effort with intermediate caching. but i believe this patch should exist in upstream as we were keeping data here and not signaling the same into system while loading postcar. Not sure if APL implementation also requires that ?
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 1:
(1 comment)
Patch Set 1:
Patch Set 1:
(1 comment)
I'm not sure we want to go down this route because of how painful all the various corner cases are when wanting WB cache type for increasing loading speed ramstage. microarchitecture details are making consistency hard.
no, as we discussed, WB might have hard to track. this is just to conclude the WB effort with intermediate caching. but i believe this patch should exist in upstream as we were keeping data here and not signaling the same into system while loading postcar. Not sure if APL implementation also requires that ?
coherency definitely wasn't complete, but much of that was handled with the assumption the writes were coherent (even if slow by writing to UC memory).
https://review.coreboot.org/c/coreboot/+/34991/1/src/arch/x86/postcar_loader... File src/arch/x86/postcar_loader.c:
https://review.coreboot.org/c/coreboot/+/34991/1/src/arch/x86/postcar_loader... PS1, Line 69:
do you mean pcf->stack and pcf->stack_top should point to same address ?
See line 32 above. pcf->stack gets manipulated as things are pushed on it. pcf->stack_top - pcf->stack is the amount of data pushed on to the stack.
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 1:
(1 comment)
https://review.coreboot.org/c/coreboot/+/34991/1/src/arch/x86/postcar_loader... File src/arch/x86/postcar_loader.c:
https://review.coreboot.org/c/coreboot/+/34991/1/src/arch/x86/postcar_loader... PS1, Line 69:
See line 32 above. pcf->stack gets manipulated as things are pushed on it. […]
i missed line 32. got it now
Hello Aaron Durbin, build bot (Jenkins),
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/34991
to look at the new patch set (#2).
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
arch/x86: Include stack_top region into postcar_frame
This patch signals to the system that stack region also needs to be accounted for as it holds MTRR related values.
Change-Id: I9279bbd66be0ad309bdabbbb90bf59c6f5967c47 Signed-off-by: Aaron Durbin adurbin@chromium.org Signed-off-by: Subrata Banik subrata.banik@intel.com --- M src/arch/x86/include/arch/cpu.h M src/arch/x86/postcar_loader.c 2 files changed, 11 insertions(+), 4 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/91/34991/2
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 2: Code-Review+1
Hello Aaron Durbin, build bot (Jenkins),
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/34991
to look at the new patch set (#4).
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
arch/x86: Include stack_top region into postcar_frame
This patch signals to the system that stack region also needs to be accounted for as it holds MTRR related values.
Change-Id: I9279bbd66be0ad309bdabbbb90bf59c6f5967c47 Signed-off-by: Aaron Durbin adurbin@chromium.org Signed-off-by: Subrata Banik subrata.banik@intel.com --- M src/arch/x86/include/arch/romstage.h M src/arch/x86/postcar_loader.c 2 files changed, 11 insertions(+), 4 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/91/34991/4
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4:
Patch Set 2: Code-Review+1
Anything we have to do further on this ?
Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4: Code-Review-2
I don't understand this commit, more descriptive commit message perhaps required?
First, this is titled arch/x86, althoug it will only make a difference on intel/apollolake where empty weak platform_segment_loaded() has an override.
Second, in the state master branch currently is, while struct postcar_frame within CAR, the created stack is entirely in CBMEM? So intel/apollolake platform_segment_loaded() is a no-op?
This commit is in my opinion somehow tied to POSTCAR_STAGE=n developments and does not have to be merged until we have decisions about them. Let me know if I misunderstood something. If I see relevant +2 I will change my vote to -1.
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4:
Patch Set 4: Code-Review-2
I don't understand this commit, more descriptive commit message perhaps required?
First, this is titled arch/x86, althoug it will only make a difference on intel/apollolake where empty weak platform_segment_loaded() has an override.
it will matter for APL because it implements platform_segment_loaded() to flush_l1d_to_l2() hence it might miss a valid range where actually the data been stored (while pushing into stack). Like its been letting platform_segment_loaded() know about stack_top_ptr, it should also info about stack current pointer and size of data been written into.
Second, in the state master branch currently is, while struct postcar_frame within CAR, the created stack is entirely in CBMEM? So intel/apollolake platform_segment_loaded() is a no-op?
why u said platform_segment_loaded() is no-op?
This commit is in my opinion somehow tied to POSTCAR_STAGE=n developments and does not have to be merged until we have decisions about them. Let me know if I misunderstood something. If I see relevant +2 I will change my vote to -1.
No its not, as i have explained above about why this stack region also need to inform, irrespective of its bene postcar_stage=y or n. i guess we are lucky that APL didn't complain but looks like we are ignoring a range where actual data been stored.
@Aaron, do you think this is more specific to APL as you have implemented platform_segment_loaded() in apl/car.c ?
Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4:
@Aaron, do you think this is more specific to APL as you have implemented platform_segment_loaded() in apl/car.c ?
/* Bail out if loaded program segment does not lie in CAR region. */ if (!start_car_check && !end_car_check) return;
That's what apollolake/car.c currently has, maybe you have followup work to change it, but with pcf->stack in CBMEM this commit does not do anything?
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4:
Patch Set 4:
@Aaron, do you think this is more specific to APL as you have implemented platform_segment_loaded() in apl/car.c ?
/* Bail out if loaded program segment does not lie in CAR region. */ if (!start_car_check && !end_car_check) return;
That's what apollolake/car.c currently has, maybe you have followup work to change it, but with pcf->stack in CBMEM this commit does not do anything?
This commit helps to mark a region where we have stored MTRR values in stack which was getting ignored previously. if you could try to dump value at pcf->stack, will help to understand. i have debugger connected which helped me to understand what we are keeping in this region and later not informing platform_segment_loaded(). So far only APL implemented the weak it might bother only APL but it might applicable for all.
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4:
Patch Set 4:
Patch Set 4:
@Aaron, do you think this is more specific to APL as you have implemented platform_segment_loaded() in apl/car.c ?
/* Bail out if loaded program segment does not lie in CAR region. */ if (!start_car_check && !end_car_check) return;
That's what apollolake/car.c currently has, maybe you have followup work to change it, but with pcf->stack in CBMEM this commit does not do anything?
This commit helps to mark a region where we have stored MTRR values in stack which was getting ignored previously. if you could try to dump value at pcf->stack, will help to understand. i have debugger connected which helped me to understand what we are keeping in this region and later not informing platform_segment_loaded(). So far only APL implemented the weak it might bother only APL but it might applicable for all.
Check this line https://github.com/coreboot/coreboot/blob/b1af16a4242d42feb0150c3a8c6fef41c7...
we are basically doing like mov esp, dword ptr [post_car_stack_top]; where post_car_stack_top = 0x99c243c0 [this we are signaling using platform_segment_loaded(stack_top_ptr) code below]
prog_segment_loaded((uintptr_t)stack_top_ptr, sizeof(uintptr_t), SEG_FINAL);
but after this instruction execute, what value will load into esp is 0x99c29fd8 = pcf->stack, we are not signaling this address using platform_segment_loaded()
purpose of this CL is to inform about the pcf->stack till its size where we have those postcar_frame been written
prog_segment_loaded(pcf->stack, pcf->stack_top - pcf->stack, SEG_FINAL);
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4:
This commit is in my opinion somehow tied to POSTCAR_STAGE=n developments and does not have to be merged until we have decisions about them. Let me know if I misunderstood something. If I see relevant +2 I will change my vote to -1.
No its not, as i have explained above about why this stack region also need to inform, irrespective of its bene postcar_stage=y or n. i guess we are lucky that APL didn't complain but looks like we are ignoring a range where actual data been stored.
@Aaron, do you think this is more specific to APL as you have implemented platform_segment_loaded() in apl/car.c ?
prog_segment_loaded() was introduced for that as well as some other archs. However, the semantics aren't super clear (my fault) if it's for coherency purposes or not. postcar loader (or even ramstage) are implicitly assuming the target address regions are coherent. This actually plays out in practice, currently, because the target DRAM regions are UC on x86. By definition there is no coherency issue since everything hits DRAM. If one wants to add WB caching to the target regions (all of cbmem in this case + tseg for stage cache) then now cache management routines are required. It gets more complicated when one is doing this while utilizing CAR (either stack/data or code) as it depends on CAR implementation and uarch. prog_segment_loaded() can be used for that purpose. It does get hairy pretty quickly because all the memory touched during load isn't explicitly tracked since there's an implicit assumption about the loading inherently being coherent.
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4:
Patch Set 4:
This commit is in my opinion somehow tied to POSTCAR_STAGE=n developments and does not have to be merged until we have decisions about them. Let me know if I misunderstood something. If I see relevant +2 I will change my vote to -1.
No its not, as i have explained above about why this stack region also need to inform, irrespective of its bene postcar_stage=y or n. i guess we are lucky that APL didn't complain but looks like we are ignoring a range where actual data been stored.
@Aaron, do you think this is more specific to APL as you have implemented platform_segment_loaded() in apl/car.c ?
prog_segment_loaded() was introduced for that as well as some other archs. However, the semantics aren't super clear (my fault) if it's for coherency purposes or not. postcar loader (or even ramstage) are implicitly assuming the target address regions are coherent. This actually plays out in practice, currently, because the target DRAM regions are UC on x86. By definition there is no coherency issue since everything hits DRAM. If one wants to add WB caching to the target regions (all of cbmem in this case + tseg for stage cache) then now cache management routines are required. It gets more complicated when one is doing this while utilizing CAR (either stack/data or code) as it depends on CAR implementation and uarch. prog_segment_loaded() can be used for that purpose. It does get hairy pretty quickly because all the memory touched during load isn't explicitly tracked since there's an implicit assumption about the loading inherently being coherent.
Thanks Aaron for clearing our the assumption and implicit requirement of why prog_segment_loaded() been introduced and what we like to achieve.
Question: do you like to see this CL going in or you think its more of an exploratory work?
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4:
Patch Set 4:
Patch Set 4:
This commit is in my opinion somehow tied to POSTCAR_STAGE=n developments and does not have to be merged until we have decisions about them. Let me know if I misunderstood something. If I see relevant +2 I will change my vote to -1.
No its not, as i have explained above about why this stack region also need to inform, irrespective of its bene postcar_stage=y or n. i guess we are lucky that APL didn't complain but looks like we are ignoring a range where actual data been stored.
@Aaron, do you think this is more specific to APL as you have implemented platform_segment_loaded() in apl/car.c ?
prog_segment_loaded() was introduced for that as well as some other archs. However, the semantics aren't super clear (my fault) if it's for coherency purposes or not. postcar loader (or even ramstage) are implicitly assuming the target address regions are coherent. This actually plays out in practice, currently, because the target DRAM regions are UC on x86. By definition there is no coherency issue since everything hits DRAM. If one wants to add WB caching to the target regions (all of cbmem in this case + tseg for stage cache) then now cache management routines are required. It gets more complicated when one is doing this while utilizing CAR (either stack/data or code) as it depends on CAR implementation and uarch. prog_segment_loaded() can be used for that purpose. It does get hairy pretty quickly because all the memory touched during load isn't explicitly tracked since there's an implicit assumption about the loading inherently being coherent.
Thanks Aaron for clearing our the assumption and implicit requirement of why prog_segment_loaded() been introduced and what we like to achieve.
Question: do you like to see this CL going in or you think its more of an exploratory work?
I don't think this hurts anything. However, I think we should verify the stage cache loading works as well. I think it's important we have solutions for all the cases -- not just partial ones.
Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4: Code-Review-1
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4:
Patch Set 4:
Patch Set 4:
Patch Set 4:
This commit is in my opinion somehow tied to POSTCAR_STAGE=n developments and does not have to be merged until we have decisions about them. Let me know if I misunderstood something. If I see relevant +2 I will change my vote to -1.
No its not, as i have explained above about why this stack region also need to inform, irrespective of its bene postcar_stage=y or n. i guess we are lucky that APL didn't complain but looks like we are ignoring a range where actual data been stored.
@Aaron, do you think this is more specific to APL as you have implemented platform_segment_loaded() in apl/car.c ?
prog_segment_loaded() was introduced for that as well as some other archs. However, the semantics aren't super clear (my fault) if it's for coherency purposes or not. postcar loader (or even ramstage) are implicitly assuming the target address regions are coherent. This actually plays out in practice, currently, because the target DRAM regions are UC on x86. By definition there is no coherency issue since everything hits DRAM. If one wants to add WB caching to the target regions (all of cbmem in this case + tseg for stage cache) then now cache management routines are required. It gets more complicated when one is doing this while utilizing CAR (either stack/data or code) as it depends on CAR implementation and uarch. prog_segment_loaded() can be used for that purpose. It does get hairy pretty quickly because all the memory touched during load isn't explicitly tracked since there's an implicit assumption about the loading inherently being coherent.
Thanks Aaron for clearing our the assumption and implicit requirement of why prog_segment_loaded() been introduced and what we like to achieve.
Question: do you like to see this CL going in or you think its more of an exploratory work?
I don't think this hurts anything. However, I think we should verify the stage cache loading works as well. I think it's important we have solutions for all the cases -- not just partial ones.
Yes, stage cache loading is working fine right, we don't see any issue. I have run this entire patchsets on KBL, CML, ICL. Can you please let me know which one you like to check ?
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Patch Set 4:
Patch Set 4:
Patch Set 4:
Patch Set 4:
Patch Set 4:
This commit is in my opinion somehow tied to POSTCAR_STAGE=n developments and does not have to be merged until we have decisions about them. Let me know if I misunderstood something. If I see relevant +2 I will change my vote to -1.
No its not, as i have explained above about why this stack region also need to inform, irrespective of its bene postcar_stage=y or n. i guess we are lucky that APL didn't complain but looks like we are ignoring a range where actual data been stored.
@Aaron, do you think this is more specific to APL as you have implemented platform_segment_loaded() in apl/car.c ?
prog_segment_loaded() was introduced for that as well as some other archs. However, the semantics aren't super clear (my fault) if it's for coherency purposes or not. postcar loader (or even ramstage) are implicitly assuming the target address regions are coherent. This actually plays out in practice, currently, because the target DRAM regions are UC on x86. By definition there is no coherency issue since everything hits DRAM. If one wants to add WB caching to the target regions (all of cbmem in this case + tseg for stage cache) then now cache management routines are required. It gets more complicated when one is doing this while utilizing CAR (either stack/data or code) as it depends on CAR implementation and uarch. prog_segment_loaded() can be used for that purpose. It does get hairy pretty quickly because all the memory touched during load isn't explicitly tracked since there's an implicit assumption about the loading inherently being coherent.
Thanks Aaron for clearing our the assumption and implicit requirement of why prog_segment_loaded() been introduced and what we like to achieve.
Question: do you like to see this CL going in or you think its more of an exploratory work?
I don't think this hurts anything. However, I think we should verify the stage cache loading works as well. I think it's important we have solutions for all the cases -- not just partial ones.
Yes, stage cache loading is working fine right, we don't see any issue. I have run this entire patchsets on KBL, CML, ICL. Can you please let me know which one you like to check ?
stage cache can utilize cbmem or tseg. If those regions are marked as WB cacheable, it's the same problem as what this patch is trying to correct -- ensuring dirty lines make it to dram. However, loading from stage cache is also an issue.
For initial loading: stage_cache_add() is used to cache the contents of the loaded program. If this is done when WB caching attributes are covering the stage cache region (cbmem or tseg) then there are dirty lines there. Both ext_stage_cache and cbmem_stage_cache both just memcpy() into the region. There's nothing that ensures that region, if marked WB cacheable, hits dram.
The cbfs_prog_stage_load() and rmodule_stage_load() loading code have the requisite prog_segment_loaded() calls. That is why those are covered for the text, data, and bss segments.
For loading during resume: stage_cache_load_stage() is utilized which is a glorified memcpy() but in reverse from the initial loading. Same issues apply w.r.t. the target region being marked WB cacheable. However, instead of cbfs_prog_stage_load() and rmodule_stage_load() which have the necessary prog_segment_loaded() calls for the text, data, and bss there's nothing there. finalize_load() in postcar_loader handles the postcar stack frame but nothing else. Thus, we're exposed on the resume path as well.
Those are the cases I was referring to w.r.t. having partial solutions. None of these scenarios exists right now because we aren't adding WB cacheable regions to the MTRR solution utilized while operating with CAR. Writes are hitting DRAM directly which means everything is coherent. This CL doesn't fix existing use-cases, but it does make things more correct. However, as I noted above there are still issues lurking if one attempted to pursue making some of these target regions cacheable. postcar stage itself remains relatively small, and that's why we don't see as big of a penalty for loading it as opposed to trying to load ramstage (way bigger) from romstage directly. Once we get into postcar stage we're running out of ram with a fuller MTRR solutions and can speed up loading and running. The only little bit of execution from UC ram is when we tear down and initialize a new set of MTRRs.
Subrata Banik has abandoned this change. ( https://review.coreboot.org/c/coreboot/+/34991 )
Change subject: arch/x86: Include stack_top region into postcar_frame ......................................................................
Abandoned
will write case study on WB MTRR implication later
-
Aaron Durbin (Code Review) -
Kyösti Mälkki (Code Review)
-
Subrata Banik (Code Review)