On 5/4/20 8:54 PM, 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. >
Hi Jan, Thank you for your time and for the deeper review. All my comments are in the related commits. I also think that the two bigger issues you pointed out can be easily solved. Luca >>>> As you likely read, there are better chances in sight to also address >>>> the root cell issue by booting Jailhouse from a loader. >>> >>> I share the same view. >>> >>> On the other hand, it ties the cache colouring with the >>> Linux-independent boot. This is not ideal from an quality perspective, >>> because it introduces a dependency between otherwise unrelated features, >>> including one definitely optional (as long as Jailhouse will stay a >>> "Linux-based hypervisor"). Also, from a process perspective, it forces >>> the colouring-related activities and deliveries to be postponed after >>> reaching a somewhat stable architecture for the independent loader >>> (colouring pages is a loader matter). >>> >>> The other option is the hot-remapping of the root-cell memory, which we >>> already wrote and tested on an older version of Jailhouse extended with >>> a SMMU support. From a quality perspective, it looks comparable, and it >>> does not introduces constraints on the development process. >>> >> >> As pointed out back then, there are still open questions regarding the >> reliability of such a hot-remapping approach, besides the complexity. >> >> Anyway, we now do have SMMU support in Jailhouse (first issue to >> report against your series, patch 9 ;) ), we could look into that >> systematically. >> >>> >>>> That would then leave us only with the question how to handle the >>>> hypervisor itself /wrt coloring. >>> >>> Correct. >>> >>> >>>> Provided that can buy us worthwhile improvements. >>> >>> We already have experimentally proven on two other hypervisors (Xen and >>> Bao) that the interrupt response time hugely depends on the cache >>> performances of the hypervisor's routines for guest injection. Cache >>> partitioning is therefore mandatory for predictability. >>> >> >> What measures did you apply on the hypervisors? Replicate the code >> into memory that has the "right" local color? Ensure that core- and >> guest-local data is in color memory? How did you handle naturally >> shared r/w data structures? > > These questions are still open. I don't see hypervisor coloring as a > must-have for starting to merge things at all. But I'd like to have some > idea of the structures and interfaces we merge will not cause massive > breakages when adding that later. > > Jan > -- 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 jailhouse-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/73e484f4-5473-97a6-424c-15435fa67324%40gmail.com.
signature.asc
Description: OpenPGP digital signature
