[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, 8 Jan 2024, Carlo Nonato wrote:
> Hi Jan,
> 
> On Mon, Jan 8, 2024 at 5:40 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >
> > On 08.01.2024 17:31, Carlo Nonato wrote:
> > > On Mon, Jan 8, 2024 at 4:32 PM Julien Grall <julien@xxxxxxx> wrote:
> > >> 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.
> > >
> > > What I'm saying is that Xen would crash before even reaching this point 
> > > if no
> > > colors were provided. Let's say that the toolstack or whatever hypercall 
> > > user
> > > isn't calling this domctl at all (or not at the right time), then the 
> > > domain
> > > colored allocator would always return null pages since there are no 
> > > colors.
> > > We would have a crash and your if (or mine) would be useless.
> >
> > Why is it that you can't simply allocated arbitrary memory if coloring
> > information wasn't set up front? Aiui that'll be required anyway, as
> > there shouldn't be a restriction that all domains have to use coloring.
> 
> If coloring is enabled all domains are colored. It's one of our first
> assumptions. We haven't developed something that works hybridly and supporting
> that would require some rework.

I think that's a good assumption and I wouldn't go in the direction of
supporting a mix of colored and non-colored. To benefit from cache
coloring, all domains need to be colored, otherwise a single non-colored
domain could thrash the cache of everyone else.

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.