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" choice. We would like to stress that we
need it to be aligned with the concept of colored memory that we are
proposing in v2. This notion is present: in the user configuration and
documentation, and also in the hypervisor code. Namely, given a color
assignment, a memory region, and a size, we want to map *only* the
needed pages that satisfy the size request. I.e., not to assign *all*
the pages of the given colors within the given region, possibly
exceeding the size request. In other words, the size parameter is meant
as the real size to be mapped, not the place where the find it.
I didn't finish that part either: I also believe that "size" of a region
should reflect the physical size, not the virtually expanded one. That
virtual size makes it really hard to read configurations now. Yes, there can
be tooling (config checker), but when you start to rearrange regions you
will continuously run into those overlap issues because region do not really
end where phys_start+size suggests.
I don't think we have very much choice, here. We need to pick one
between:
- having a true region size parameter and favour misunderstandings about
the end address, since phys_start + size != phys_end (v2 proposal);
- ease reasoning about the real end address while using 'size' as the
'phys_spanning_size', since end-start != size (v1 proposal and your
currently favourite).
The situation is symmetrical, but about one point: v1 make the 'size'
semantics explicitly incoherent. We would avoid that.
So does v2, see below.
To mitigate the configuration difficulties without the help of the
tooling level, we can promote a good configuration habit and comments
like this:
size = CELLSIZE;
// phys_end = phys_start + size*(MAXCOLORS/CELLCOLORS)
...which would be only true if you aligned phys_start on way-size.
Irrespective of the semantic of size, such an alignment should be a
requirement to enforce in fact. Otherwise, things become even more
confusing.
BTW, another - though massively invasive - option to help clarify the
situation is to rename "size" to either "virt_size" or
"phys_[spanning_]size" because that is what actually happens
semantically in the presence of colors.
Coloring does not go well with manual configuration, I guess that is clear.
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/5369cf35-5291-440d-642a-9f23cccc854a%40siemens.com.
