Hi, I just wanted to add some pointers about related uses of similar concepts/approaches: On Fri, Nov 30, 2018, 12:07 송대영

Hi, I read "Improving Interrupt Response Time in a Verifiable Protected Microkernel" paper.

This paper improved IPC performance by using cache pinning and I want to know how to implement cache pinnng.

Another major use of forcing data to stay in cache is during early boot, while configuring memory controllers and physical address layout.

But this paper doesn't refer how to manipulate cache lines.

The bootloader implementation in Libreboot accomplishes the cache-as-ram mode by AFAIK using (a) write-back mode and ensuring through access patterns/used address space that no eviction will be initiated.

Would you give me some methods how to read cache lines and write cache lines?

You can find early boot memory controller setup code in Libreboot or it's ancestor Coreboot. [The following is aggregated as a TL;DR below, feel free to skip the off-topic rambling.] This is extremely early stage code, also required for things like hot-plug DIMM support and likely also things like dynamically changing dram bus clocks for e.g. a new sleep mode much shallower than S3 (ACPI suspend-to-ram) and simultaneously allowing cheap low-speed computation through e.g. extreme undervolting of the CPU. A gradual increase of dram supply voltage might allow — if combined with software-side FEC (forward error corretion) — extremely low-power (and slower to resume) long(er) term suspend-to-ram by driving the memory at a far higher raw BER (bit error rate) than 8b/10b standard ECC can compensate securely. (Theoretically, ECC could likely be combined in blocks of a cache line, to allow correcting up to 128 simultaneous bit errors (I think? Imagine mapping from the 2^(8*128) bits of data to the 2^(10*128) bits of ram by treating the latter as a single gray-code number, then spacing the values of data in this mapping evenly over the possible gray-code values, with the correcting reverse mapping converting an arbitrary value of the gray-code to the nearest value (and then it's data-value) that was assigned a value from the smaller (by a factor of 2^((10-8)*128) ) set of data values. Follow up with me if you want, and feel free to suggested a better mailing list for any — possibly significant — further discussion.) and detecting even more, but that would probably require dedicated silicon in the memory or it's controller (the latter should offer better logic gate fabrication). ) This could maybe approach standby times for a laptop on the order of months. Please tell me, where you've found docs/code that does this cache-abuse if you find it. TL;DR: cache-abuse and memory controller configuration allow fancy things, which I'd like to estimate time-to-POC for. I wanted to check commonly used, cache-abusing code, but gave up searching. (Because a subsequent POC has been predicted to not be worth the opportunity cost of having learned the highly specialized technology that is x86 early boot/hardware-init code for a "fun" side project.)

_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel

Sincerely, Merlin Kramer PS: Apologies for the off-topic, I had to hydrate on coffee and went down to deep into the rabbit hole of abusing modern microelectronic for fun and (un)profitable "gainz". I hope it was at least an interesting dive down the hole of what hardware could do if firmware wasn't closed-source and the inner design wasn't shielded in form of trade secrets.