On 11/01/2021 12:44, Jan Kiszka wrote:
> On 23.11.20 21:46, Andrea Bastoni wrote:
>> Add generic architecture API layer needed to implement coloring:
>>
>> arch_color_map_memory_region() // cell_create
>> arch_color_unmap_memory_region() // cell_destroy
>> arch_color_remap_to_root() // cell_load
>> arch_color_unmap_from_root() // cell_start
>>
>> Currently only arm64 will implement the API. arm32 could be also a
>> possible target for coloring. x86 already features CAT support.
>>
>> ARM architectures also implement:
>>
>> arm_color_dcache_flush_memory_region() // range flushing
>> arm_color_init() // hook for the initialization of
>> coloring
>>
>> The architecture operations implement functionalities that consider the
>> color assigned to a memory region when performing the VA <-> PA
>> translation.
>>
>> This patch uses a reserved memory region as mapping-scratchpad to
>> perform coloring during the load operations. The mapping is removed
>> during the start operation. A later patch makes the start of the memory
>> region configurable.
>>
>> Refer to the Documentation/cache-coloring.md for an introduction of the
>> coloring isolation software techniques.
>>
>> Signed-off-by: Andrea Bastoni <[email protected]>
>> ---
>> driver/cell.c | 10 +++-
>> .../arch/arm-common/include/asm/dcaches.h | 8 +++
>> hypervisor/arch/arm-common/mmu_cell.c | 52 ++++++++++------
>> hypervisor/arch/arm/include/asm/coloring.h | 59 +++++++++++++++++++
>> hypervisor/arch/arm64/include/asm/coloring.h | 59 +++++++++++++++++++
>> hypervisor/arch/arm64/setup.c | 3 +
>> hypervisor/arch/x86/include/asm/coloring.h | 45 ++++++++++++++
>> hypervisor/control.c | 56 ++++++++++++------
>> hypervisor/include/jailhouse/control.h | 7 +++
>> include/jailhouse/cell-config.h | 6 ++
>> 10 files changed, 267 insertions(+), 38 deletions(-)
>> create mode 100644 hypervisor/arch/arm/include/asm/coloring.h
>> create mode 100644 hypervisor/arch/arm64/include/asm/coloring.h
>> create mode 100644 hypervisor/arch/x86/include/asm/coloring.h
>>
>
> ...
>
>> diff --git a/include/jailhouse/cell-config.h
>> b/include/jailhouse/cell-config.h
>> index 472cb4bb..e62e692b 100644
>> --- a/include/jailhouse/cell-config.h
>> +++ b/include/jailhouse/cell-config.h
>> @@ -115,6 +115,7 @@ struct jailhouse_cell_desc {
>> #define JAILHOUSE_MEM_LOADABLE 0x0040
>> #define JAILHOUSE_MEM_ROOTSHARED 0x0080
>> #define JAILHOUSE_MEM_NO_HUGEPAGES 0x0100
>> +#define JAILHOUSE_MEM_COLORED 0x0200
>> #define JAILHOUSE_MEM_IO_UNALIGNED 0x8000
>> #define JAILHOUSE_MEM_IO_WIDTH_SHIFT 16 /* uses bits 16..19 */
>> #define JAILHOUSE_MEM_IO_8 (1 << JAILHOUSE_MEM_IO_WIDTH_SHIFT)
>> @@ -127,8 +128,13 @@ struct jailhouse_memory {
>> __u64 virt_start;
>> __u64 size;
>> __u64 flags;
>> + /* only meaningful with JAILHOUSE_MEM_COLORED */
>> + size_t colors;
>
> Wrong type. Needs to be one that specifies the width in bits.
Right. Since only arm64 supports coloring, I wanted to keep the compilation for
arm32 simpler. But yes, it should be changed to u64.
> This needs to be bitmask, one bit per possibly color, right? Do we need
> 64, or even 128? Or would 32 suffice in practice? In the latter case, we
> could consider shrinking flags to 32 bits.
Good point. We discussed it in the past (e.g., the version with next_colored()
and next_color() used 128 bits). But we went down to 64 bits max (1 bit per
color) because it should cover all the practical cases for the embedded market.
The expectation is that when / if there's the need to have more colors for the
embedded market, hardware solutions like MPAM will be available.
--
Thanks,
Andrea Bastoni
--
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/0c619e2e-7194-bac0-013c-32c3eea9765f%40tum.de.
