Hi, I just wanted to add some pointers about related uses of similar concepts/approaches:
On Fri, Nov 30, 2018, 12:07 송대영 <[email protected] wrote: > 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 > [email protected] > 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.
_______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
