On 5/4/20 8:33 PM, Jan Kiszka wrote: > On 21.04.20 12:03, 'Marco Solieri' via Jailhouse wrote: >> From: Luca Miccio <[email protected]> >> >> 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. Thanks, Luca > Jan > -- 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/0af1c1c8-52ee-f822-66e5-c7926fac8596%40gmail.com.
signature.asc
Description: OpenPGP digital signature
