Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34791 )
Change subject: soc/intel/cannonlake: Speed up postcar loading using intermediate caching ......................................................................
Patch Set 6:
(2 comments)
https://review.coreboot.org/c/coreboot/+/34791/5/src/soc/intel/cannonlake/ro... File src/soc/intel/cannonlake/romstage/romstage.c:
https://review.coreboot.org/c/coreboot/+/34791/5/src/soc/intel/cannonlake/ro... PS5, Line 142: set_var_mtrr(mtrr, base, size, MTRR_TYPE_WRPROT);
i don't think its anything specific to NEM enhance or CQOS. […]
One can dynamically add to the MTRR solution. However, I'm not sure that it works on all x86 systems when CD=1. CD=1 turns on the use of caches -- I don't think it says anything about making the registers take effect (though that could be an implementation), and such behavior would be surprising to me.
Also, the assumption here is that the address range being requested is not overlapping with CAR address space. If it was then, yes, everything is busted.
https://review.coreboot.org/c/coreboot/+/34791/5/src/soc/intel/cannonlake/ro... PS5, Line 177: enable_ramstage_caching(top_of_ram, top_of_ram_size);
NEM enhance or CQOS is special because it treated data and code cache differently than whats been do […]
w.r.t. invd instruction in exit_car.S doesn't matter. Things are already loaded and flushed out by way of prog_segment_loaded(). The expectation is that by the time invd is ran dirty lines in the cache are not needed and therefore lost.
The name of the function is confusing. It's marking the top of ram WB as noted.