On 11.05.20 11:07, Luca Miccio wrote:
On 5/6/20 6:54 PM, Jan Kiszka wrote:
On 06.05.20 18:42, Luca Miccio wrote:
On 5/4/20 8:33 PM, Jan Kiszka wrote:
On 21.04.20 12:03, 'Marco Solieri' via Jailhouse wrote:
From: Luca Miccio <lucmic...@gmail.com>
Currently Jailhouse loads inmate's binaries by mapping its memory
region
to the root cell. When coloring is enabled this operation becomes
not trivial. To avoid logic duplication in the driver module,
use a special memory space when loading to colored regions. This
convenient memory space starts from a fixed address defined by
`col_loads_address` and will be mapped by the hypervisor using the same
size and coloring configuration as the inmate.
Since there could be platforms with different memory space layouts, the
choice of `col_loads_address` has to be done accordingly.
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.
This is better than the hypercall in v1, but I still dislike the
approach for the complexity growth in the hypervisor.
I see the point that some logic - namely the strip width calculation -
would have to be duplicated into the Linux driver, but it feels to me
that this would be a better alternative overall. Did you think through
or even try such an approach at all?
Yes. Actually it was our first implementation, the v0 one. Our concern
was (and still is) the duplication of coloring logic between hypervisor
and Linux driver. We put so much time into this problem and we came up
with this solution and we think it seems to be overall the best one. I
also understand and I agree that this solution adds some complexity to
the hypervisor but even if we move some logic to Linux, a part of the
complexity will remain in the hypervisor.
Moreover, moving coloring logic to the driver opens up the problem on
how to copy in "strided" mode based on the coloring configuration. We
did it by copying one page at a time, using the next_colored in the
driver module (duplicating the code) but this approach was too expensive
when loading larger images (e.g, Linux inmate).
One solution that I see is the following:
- during cell load, Jailhouse remaps the inmate memory to root cell as
usual but in colored mode
- the "special" memory region mentioned in the commit is created by
Linux instead of Jailhouse
- the copy is performed virtually sequential
The idea here is to exploit the jailhouse_ioremap function in the driver
module.
With this solution the only complexity that remains in the hypervisor is
the memory management for the root cell that is introduced in patch 5
without the "special" region part.
I haven't fully thought this through, but I wonder if storing
- maximum number of colors
- color stride width
instead of llc way size in the platform data and using that also in the
driver would obsolete a lot of logic in the driver and the hypervisor.
Granted, that would push some of it to an offline calculation. That that
would be a typical Jailhouse pattern.
I see the point but who will provide this values in the platform data?
Are they calculated or?
Yes, they would have to be pre-calculated. For convenience, we could
discuss to do that in the kernel driver if those values are unset and
coloring is requested.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
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 jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/942fdfa6-5be7-e17e-d447-d1c2f41da80f%40siemens.com.
