On 02.02.21 17:44, Bram Hooimeijer wrote:
> Dear Jan, dear Jailhouse community, 
> 
> We are running Jailhouse on an Intel X86 server-grade processor and use the 
> Jailhouse CAT module to isolate cache usage between cells. This patch series 
> contains several fixes to the CAT module, to ensure the root cell remains 
> isolated from non-root cells.
> I have tried to explain the grounds for change in each patch, with counter 
> examples where needed. 
> 
> Jan, I hope to extend the CAT module in the future to allow each cell to 
> change its CBM during run-time, e.g. to distinguish critical and non-critical 
> sections. Now, the module dynamically allocates each cell a COS, and 
> considers any write to MSR_IA32_L3_MASK an illegal VM exit.

Right, the simpler model.

> Disregarding the last patch in this series, each cell had its own unique COS, 
> which might justify a cell changing its own CBM, for example as long as it is 
> a subset of the CBM in the config file. However, in the last patch of the 
> series I drop this behavior due to issues on larger CPUs -- the number of 
> CPUs might outrange the number of COSes available. 

One COS -> one cell is so far the model. If you have one cell -> one
CPU, you may hit that limit, true. May I ask how large your systems are?

> 
> Allowing a cell to cleanly edit its own CBM, without affecting other cells, 
> is difficult if the COSes are dynamically assigned at cell creation. That is 
> why I am considering to extend the cache-regions in the config file to allow 
> for a statically allocated COS -- and make this a statically partitioned 
> resource just like e.g. memory.
> What are your thoughts on this? Any reason why you omitted this in the first 
> place, and opted for dynamically allocated COSes?

The "why" is generally best answered by "it's simpler to implement in
the hypervisor". Any moderation of hardware features add code to the
hypervisor. And an interface that could break or be misused if not done
properly

So, you want multiple COS per cell in order to hand out sub-control over
the cell's CBM to it and to intra-cell partitioning? Sounds complex from
the hypervisor POV, though I understand that there can be use cases.

> 
> Thanks, 
> 
> Best regards, Bram Hooimeijer
> 
> Bram Hooimeijer (6):
>   x86/cat.c: Fix type freed_mask
>   x86/cat.c: Fix CBM for non-root cell w/ root COS.
>   x86/cat.c: Fix returning bits upon cell exit
>   x86/cat.c: Fix off-by-one error
>   x86/cat.c: Fix overlap on moving the root COS CBM
>   x86/cat.c: Add COS re-use in cells with same mask.
> 
>  hypervisor/arch/x86/cat.c | 140 ++++++++++++++++++++++++++------------
>  1 file changed, 95 insertions(+), 45 deletions(-)
> 

Thanks for these, need to dig into the details.

I have locally an unfinished CAT rework pending that addresses L2
partitioning as found on Apollo Lake and newer - or conceptually also
multi-socket L3 partitioning. For that, it resolves the wrong initial
assumption that CAT is system-global. Baseline is a new CPU description,
see [1]. All that will clash with these, but it's my job to resolve that.

Jan

[1] https://github.com/siemens/jailhouse/commits/wip/new-cpu-config

-- 
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/7d1fb7a3-b427-74c2-2f2c-8bfd62453ac7%40siemens.com.

Reply via email to