Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/35187 )
Change subject: [NOTFORMERGE] soc/intel exit_car.S ......................................................................
Patch Set 2:
(2 comments)
https://review.coreboot.org/c/coreboot/+/35187/2/src/soc/intel/common/block/... File src/soc/intel/common/block/cpu/car/exit_car.S:
https://review.coreboot.org/c/coreboot/+/35187/2/src/soc/intel/common/block/... PS2, Line 48: /* Disable cache ??? */
Perhaps so, see comment on arch/x86/exit_car.S line 36.
"/* chipset_teardown_car() is expected to disable cache-as-ram. */"
That one? That doesn't say cache. It says cache as ram.
There will be no CR0.CD 1->0 transition when we return to arch/x86/exit_car.S, if we skip CR0.CD 0->1 transition here. Everyone else seems to do it. I thought both those transitions have some significance wrt MTRR reproramming.
Not really. x86 is kinda horrible here. With CR0.CD=1 it means fills (for fresh reads or fresh writes) won't go into cache. But cache is snooped for either transaction. A read can hit in cache, and so can a write (which I think flushes the line out).
As for MTRR programming proper we're disabling those below. I 99%sure that would stop the snooping since there's nothing indicating to the processor to attempt the snoop (MTRRs are disabled). Because of this data is abandoned in cache and the invd knocks down all the valid bits.
https://review.coreboot.org/c/coreboot/+/35187/2/src/soc/intel/common/block/... PS2, Line 62: /* maybe redundant ? */
There is invd once we return to caller, arch/x86/exit_car.S line 45. […]
Double invd doesn't matter unless there's a dirty line which the ABI basically says you can only use registers. That's why we keep the return value in ebx -- and not a stack. Multiple invds are ok in the current sequence, but the arch/x86/exit_car.S doesn't assume implementation details of the chipset. I do agree that invd should be on line 77 for consistency. This assumes everything dirty has been flushed from cache to memory.