Re: [PATCH v5 04/13] xen: extend domctl interface for cache coloring

[Julien Grall <julien@xxxxxxx>]

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