On 15.06.20 10:11, Marco Solieri wrote: > On Wed, May 27, 2020 at 05:20:05PM +0200, Jan Kiszka wrote: >> On 26.05.20 15:24, Marco Solieri wrote: >>> On Mon, May 04, 2020 at 08:54:32PM +0200, Jan Kiszka wrote: >>>> On 22.04.20 10:51, Jan Kiszka wrote: >>>>> On 22.04.20 09:22, Marco Solieri wrote: >>>>>> On Wed, Apr 22, 2020 at 08:42:32AM +0200, Jan Kiszka wrote: >>>>>>> On 27.03.19 13:18, Marco Solieri wrote: >>>>>>>> Predictability of memory access latency is severely menaced by the >>>>>>>> multi-core architectures where the last level of cache (LLC) is >>>>>>>> shared, jeopardizing applicability of many Arm platform in real-time >>>>>>>> critical and mixed-criticality scenarios. Support for cache coloring >>>>>>>> is introduced, a transparent software technique allowing >>>>>>>> partitioning the LLC to avoid mutual interference between inmates. >>>>>>>> [...] >>>>>>> >>>>>>> Thanks for updating this! I will refresh my caches on the topic and >>>>>>> provide feedback soon (I already have some questions and remarks but >>>>>>> I'd like to double-check them). >>>>>> >>>>>> Looking forward to hear from you. >>>>>> >>>> >>>> Done with the deeper review. Overall, the series looks fairly good. I see >>>> just two bigger open issues: >>>> >>>> - inmate loading interface >>>> - more architectural independence >>>> >>>> But I think those should be solvable. >>> >>> The major point you raise is that the impact on the hypervisor code size >>> should be minimised -- the inmate loading interface. We took a while to >>> consider and weigh the various alternative designs. >>> >>> First of all, let us consider the optimal solution in this sense. That >>> would be placing the whole colouring logic outside the hypervisor, in >>> the Linux driver, or in the userspace tools. No matter how implemented, >>> this solution would require, sooner or later, to pass to the hypervisor >>> a list of memory regions, one per each memory segment to be mapped. >>> Now, such list would grow unacceptably quickly, wasting a lot of memory >>> to store it. Take for instance a Linux inmate, and suppose 128 MiB to >>> be its memory reservation requirement. Now, assume that each >>> consecutive fragment is the shortest possible, i.e. page of 4 KiB. This >>> means we need 32 Ki elements, each sizing 16 B, which is 512 KiB in >>> total. >>> >>> This brings us to a design conclusion. The mere colouring logic -- i.e. >>> the algorithm which conceptually expands the colour selection within a >>> memory area into the lengthy list of contiguously-mapped segment >>> (next_col) -- must be placed together with the mapping function >>> (paging_create). >>> >>> We believe we can leave everything else outside the hypervisor without >>> much effort. We can move in the driver: >>> - the cache probe function (get_llc_waysize) >>> - the initialisation routines (coloring_paging_init and >>> coloring_cell_init). >>> >>> We believe this is the best compromise. >>> >>> In this case, a minor issue is also worth to be discussed. The cell >>> load function requires an IPA-contiguous mapping for the memcpy to be >>> efficient. This in turn requires such mapping to be performed by the >>> driver (we don't want to add an hypercall, right? ;-)), thus including a >>> second copy of the colouring logic (next_col). It would be nice, >>> perhaps, to have a 'common' section where to place code shared between >>> hypervisor and the driver. >> >> Thanks for the explanations. My current feeling is that I need to look >> closer into the implementation so that I can argue here on eye level. >> Will try to schedule that soon and come back to you! > > Any news about it? We have time available to follow up for the next > month or so.
Not yet. Started to look into it but got distracted again. As it is more complex than I thought, I need to find some hours of continuous work on that. Should be doable before July, though. One feedback I can already provide: Any kind of runtime validation of the colored config like color_root_cell_management has to be moved into jailhouse-config-check. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/dad08183-081d-6c31-5be6-305c39a9900a%40siemens.com.
