Hi,
On 08/01/2024 15:18, Carlo Nonato wrote:
No. I am saying that that we should not be able to allow changing the
colors after the memory has been allocated. To give an example, your
current code would allow:
1) Setup the P2M pools or allocate RAM
2) Set the color
This would render the coloring configuration moot.
Whether we want to allow changing the coloring before hand is a
different question and as I wrote earlier on, I don't mind if you want
to forbid that.
At the moment I'm relying on the toolstack in the sense that I know that it
will set colors right after domain creation and before memory allocation.
Calling alloc_domheap_pages() without a coloring configuration makes Xen
crash, so it's mandatory to have the configuration done before any allocation.
I know that we shouldn't rely on the toolstack this much, but I didn't
find a better way. Given this assumption, looking for an already existing
color configuration of a domain is sufficient to avoid what you are saying.
Is it possible to enforce such a constraint with domctl? > I mean to be sure
that this domctl will be called at a precise time.
Yes. You can...
Thanks.
I don't know what to check that.
You can check the size of the P2M pool (d->arch.paging.p2m_total_pages)
is still 0. I think for RAM, you can check d->tot_pages == 0.
... reject the call if either of the two fields are not zero.
Cheers,
--
Julien Grall
