On Wed, Jul 29, 2020 at 06:08:16PM +0200, Jan Kiszka wrote:
> On 29.07.20 17:32, Marco Solieri wrote:
> > On Tue, Jul 28, 2020 at 01:30:37PM +0200, Jan Kiszka wrote:
> > > On 28.07.20 13:09, Marco Solieri wrote:
> > > > Beside the "offset vs next_col"
On Wed, Jul 29, 2020 at 09:53:27AM +0200, Jan Kiszka wrote:
> On 29.07.20 00:41, Marco Solieri wrote:
> > On Tue, Jul 28, 2020 at 01:30:37PM +0200, Jan Kiszka wrote:
> > > On 28.07.20 13:09, Marco Solieri wrote:
> > > > On Tue, Jul 28, 2020 at 11:2
On Tue, Jul 28, 2020 at 01:30:37PM +0200, Jan Kiszka wrote:
> On 28.07.20 13:09, Marco Solieri wrote:
> > Beside the "offset vs next_col" choice. We would like to stress that we
> > need it to be aligned with the concept of colored memory that we are
> > proposing
On Tue, Jul 28, 2020 at 01:30:37PM +0200, Jan Kiszka wrote:
> On 28.07.20 13:09, Marco Solieri wrote:
> > On Tue, Jul 28, 2020 at 11:26:45AM +0200, Jan Kiszka wrote:
> > > On 28.07.20 11:15, Marco Solieri wrote:
> > > > On Mon, Jul 27, 2020 at 11:3
On Tue, Jul 28, 2020 at 11:26:45AM +0200, Jan Kiszka wrote:
> On 28.07.20 11:15, Marco Solieri wrote:
> > On Mon, Jul 27, 2020 at 11:39:48PM +0200, Jan Kiszka wrote:
> > > On 27.07.20 23:13, Marco Solieri wrote:
> > > > If we understand correctly your
> >
On Mon, Jul 27, 2020 at 11:39:48PM +0200, Jan Kiszka wrote:
> On 27.07.20 23:13, Marco Solieri wrote:
> > If we understand correctly your
> > implementation, you are mapping the entire memory region and then
> > copying blocks of the binary image using what you called "co
colors detection" could go
> into the driver.
Agreed. We already moved it.
--
Marco Solieri, Ph.D.
Research Fellow
High-Performance Real-Time Lab
Università degli Studi di Modena e Reggio Emilia
Ufficio 1.35 - Edificio Matematica - 213/b, via Campi - 41125 Modena
Tel: +39-059-205-55-10
On Wed, Jul 22, 2020 at 07:28:29PM +0200, Jan Kiszka wrote:
> On 22.07.20 18:42, Marco Solieri wrote:
> > On Wed, Jul 22, 2020 at 04:39:59PM +0200, Jan Kiszka wrote:
> > > On 22.07.20 16:20, Marco Solieri wrote:
> > > > On Mon, Jul 20, 2020 at 11:2
On Wed, Jul 22, 2020 at 04:39:59PM +0200, Jan Kiszka wrote:
> On 22.07.20 16:20, Marco Solieri wrote:
> > On Mon, Jul 20, 2020 at 11:29:21PM +0200, Jan Kiszka wrote:
> > > Regarding dynamic coloring, I can only repeat what I stated before,
> > > multiple times: I'm ext
ardware-management-related feature in the
hypervisor. That would be mapped in all cells, hence unprotected.
Does that make sense? If not, could you elaborate further, please?
Cheers.
--
Marco Solieri, Ph.D.
Research Fellow
High-Performance Real-Time Lab
Università degli Studi di Modena e R
On Wed, Jun 17, 2020 at 10:49:55AM +0200, Jan Kiszka wrote:
> 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 Kiszk
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:
> >&g
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:
> > &
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 appl
On Tue, Apr 21, 2020 at 12:03:42PM +0200, Marco Solieri wrote:
> This series proposes major reviews to the cache coloring support
> proposed on 2019-03-27 on this list.
As a side note, this has been tested also on NXP i.MX8 QM, using
mainline Jailhouse by just disabling NXP-specific fe
. The configuration is
cell-wide and will be used with all the memory regions flagged with
JAILHOUSE_MEM_COLORED.
If no color selection is provided by the user and coloring is enabled,
use all the available colors on the platform.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
Acked
is destroyed.
Add the missing CELL_CREATE state and introduce a management function
that handles the colored scenario for all the above phases.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
hypervisor/control.c | 128 ---
1 file changed, 119
.
Allow the user to set this value in the root-cell configuration and set
the default to 16 GiB. The latter has been empirically choosen as default
value.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
Acked-by: Angelo Ruocco
---
driver/Makefile | 4
driver/cell.h
t; version of paging_create when needed.
The colored version of paging_destroy is used only when unmapping from
the root cell since we are assuming a 1:1 mapping for it.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
hypervisor/arch/arm-common/include/asm/cell.h | 4 ++
.../arch/
mapping, since we assume that the root cell uses a 1:1 mapping
for memory regions.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
hypervisor/include/jailhouse/paging.h | 11 ++
hypervisor/paging.c | 155 ++
2 files changed, 166 insertions
-by: Luca Miccio
Signed-off-by: Marco Solieri
---
driver/cell.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/driver/cell.c b/driver/cell.c
index 50e344e5..f4bb8986 100644
--- a/driver/cell.c
+++ b/driver/cell.c
@@ -325,7 +325,13 @@ static int load_image(struct cell
From: Luca Miccio
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
Documentation/cache-coloring.md | 278
1 file changed, 278 insertions(+)
create mode 100644 Documentation/cache-coloring.md
diff --git a/Documentation/cache-coloring.md b
This series proposes major reviews to the cache coloring support
proposed on 2019-03-27 on this list [1].
We first summarize changes and then give a bird-eye view of the new
commit structure. Background and motivation can be found in the
previous proposal [1].
Changelog
-
### Suggested
From: Luca Miccio
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
configs/arm64/zynqmp-zcu102-inmate-demo-col.c | 79 +++
configs/arm64/zynqmp-zcu102-linux-demo-col.c | 128 ++
2 files changed, 207 insertions(+)
create mode 100644 configs/arm64/zynqmp
as colored.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
hypervisor/include/jailhouse/coloring.h | 96 +
include/jailhouse/cell-config.h | 8 +++
2 files changed, 104 insertions(+)
create mode 100644 hypervisor/include/jailhouse/coloring.h
diff
or root-cell, it means needs to cut off at
> least 1/8 or 1/16 memory of the whole dram space from root cell.
For example, 1/16 of 2GiB DRAM looks expendable.
> CMA is not easy to fix here...
I have not ever used CMA. Does it operate without SMMU mediation (i.e.
translation)?
Cheers.
--
Ma
d cache easily allows for 8 or 16 colours,
which means that the smallest PA granularity to assign to a given cell is 1/8 or
1/16, which is an acceptable limitation.
Cheers.
--
Marco Solieri, Ph.D.
Research Fellow
High-Performance Real-Time Lab
Università degli Studi di Modena e Reggio Emilia
On Wed, Apr 10, 2019 at 01:04:46PM +0200, Jan Kiszka wrote:
> On 10.04.19 11:24, Marco Solieri wrote:
> > > Well, maybe we can reduce the impact on struct jailhouse_memory. Do we
> > > expect >32 ways - and if so, when would we expect >64? If not, we could
> > >
On Wed, Apr 10, 2019 at 01:07:19PM +0200, Jan Kiszka wrote:
> On 27.03.19 13:18, 'Marco Solieri' via Jailhouse wrote:
> > From: Luca Miccio <206...@studenti.unimore.it>
> >
> > Add a new hypercall that maps a colored memory region to the root cell so
> > that it c
On Mon, Apr 08, 2019 at 11:53:54AM +0200, Jan Kiszka wrote:
> On 08.04.19 11:03, Marco Solieri wrote:
> > On Mon, Apr 01, 2019 at 05:37:53PM +0200, Jan Kiszka wrote:
> > > On 27.03.19 13:18, 'Marco Solieri' via Jailhouse wrote:
> > > > Predictability of memory acce
Dear Jan,
On Mon, Apr 01, 2019 at 05:37:53PM +0200, Jan Kiszka wrote:
> On 27.03.19 13:18, 'Marco Solieri' via Jailhouse wrote:
> > Predictability of memory access latency is severely menaced by the
> > multi-core architectures where the last level of cache (LLC) is shared,
&
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
igning to each memory regions half of the available colors on the
platform.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
configs/arm64/jetson-tx2-col.c | 529
configs/arm64/jetson-tx2-demo-col.c | 76
2 files changed, 605 insertions(+)
creat
From: Luca Miccio <206...@studenti.unimore.it>
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
Documentation/cache-coloring.md | 330
1 file changed, 330 insertions(+)
create mode 100644 Documentation/cache-coloring.md
diff --git a/Documen
and we are assigning to each memory regions half of
the available colors on the platform.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
configs/arm64/zynqmp-zcu102-col.c| 153 +++
configs/arm64/zynqmp-zcu102-demo-col.c | 79 ++
configs/arm64/zynqmp-
r also to the `MemoryRegion` class.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
tools/jailhouse-cell-linux | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/jailhouse-cell-linux b/tools/jailhouse-cell-linux
index 49babd92..3cf05e28 100755
--- a/tools/jailhous
ecause it is the only architecture tested.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
driver/Makefile | 1 +
driver/cell.c | 56 ++-
driver/coloring.c | 239 ++
driver/coloring.h | 52 ++
driver/main.c |
logic by keeping it all in the hypervisor.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
hypervisor/control.c | 65 +++
include/jailhouse/hypercall.h | 1 +
2 files changed, 66 insertions(+)
diff --git a/hypervisor/control.c b/hypervisor/con
imited by the page size and the LLC way size as happens on
Arm;
- calculate the next physical page address that conforms to a given colors
selection and to the bits calculated in the previous function.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
Signed-off-by: Renato Mancuso
---
i
t cell uses a 1:1 mapping for
memory regions.
Signed-off-by: Luca Miccio
Signed-off-by: Marco Solieri
---
hypervisor/arch/arm-common/mmu_cell.c | 27 -
hypervisor/control.c | 12 ++
hypervisor/include/jailhouse/paging.h | 11 ++
hypervisor/paging.c
> coloring?
Me and my team at the HiPeRT-Lab of the University of Modena and Reggio Emilia
(Italy) finalised an initial implementation few weeks ago. Find more info in a
previous message of mine on the list.
I believe we are submitting a patchset next week. Stay tuned! :-)
--
Marco Solieri,
ely if you would like further
assistance.
Best regards.
--
Marco Solieri, Ph.D.
it. We are currently defining the public release plan -- a proper RFC is
to be expected in the very near future.
Best regards.
~~
Links:
[1] http://hercules2020.eu/
--
Marco Solieri, Ph.D.
Research Associate
High-Performance Real-Time Lab
Università degli Studi di Modena e Reggio Emilia
U
43 matches
Mail list logo
