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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.01.2024 22:21, Stefano Stabellini wrote:
> 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.

In which case the tool stack not having set up coloring data first should
lead to all allocation attempts failing. No crashes whatsoever.

Jan