On 25.01.21 13:00, Andrea Bastoni wrote: > Hi Jan, > > Here a proof of concept for the cache-coloring with/without driver approach > (works, but hasn't been tested as much as the old version, and we have seen > at least one crash in our tests, but it should be sufficient to have a > discussion about the direction). > > The patches until > 0018-configs-arm64-add-coloring-example-for-qemu-arm64.patch implement the > previous coloring approach (+ bugfixing + qemu-arm64 integration). The > patches from 0019-config-always-rely-on-the-availability-of-way_size.patch > are the proof of concept to realize a colored jailhouse ioremap in the > driver, keeping the same logic between the hypervisor and the driver. > > The "get_bit_range()" is refactored in a single place already > (0020-coloring-extract-get_bit_range-logic-and-remove-offs.patch), but the > main logic needs to be replicated between hypervisor and driver [*], > coloring.c doesn't get considerably shorter, and control.c gets more > complicated because we need to distinguish when the remapping is colored and > when it's not. > > Most of the code reduction comes from the removal of the cache_layout > autodetection, which is "debug only" (and could have been removed in the > previous version as well). > > Overall I count for the previous approach (patches 01 - 18): > 42 files changed, 1337 insertions(+), 121 deletions(-) > For the new one (patches 01 - 23): > 41 files changed, 1233 insertions(+), 127 deletions(-) >
Thanks for the update. I think we are moving forward. The diffstat for the hypervisor (with include/) is getting closer to an interesting range: 32 files changed, 721 insertions(+), 122 deletions(-) But we can still do better: - make non-colored operations the special case of colored ones (e.g. map_uncolored(...) = map_colored(all_colors)), that should further reduce duplications, both in the hypervisor and the driver - make sure that only the calculation of color bars' start and size is arch-specific (where I still think it belongs to arm-common...) so that iteration & Co. can stay in the generic core - pull all coloring unrelated refactorings to the front of the series, e.g. the panic things, to allow taking them earlier - avoid needless static inline, rather provide linkable stubs on arch that do not support an implementation In addition, some consistency checks in jailhouse-config-check would probably help to make users' life easier. Or may even obsolete some runtime assertions. Jan -- Siemens AG, T RDA IOT 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/8e7872cb-ea47-9c9d-3240-f687b1ab698c%40siemens.com.
