Re: [PATCH v6 5/6] arm/dom0less: assign dom0less guests to cpupools

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

> On 8 Apr 2022, at 13:10, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 08.04.2022 13:15, Luca Fancellu wrote:
>> 
>> 
>>> On 8 Apr 2022, at 11:24, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> 
>>> On 08.04.2022 11:39, Luca Fancellu wrote:
>>>> 
>>>> 
>>>>> On 8 Apr 2022, at 10:10, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>> 
>>>>> On 08.04.2022 10:45, Luca Fancellu wrote:
>>>>>> @@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
>>>>>> /* Per-vCPU buffer size in bytes. 0 to disable. */
>>>>>> uint32_t vmtrace_size;
>>>>>> 
>>>>>> + uint32_t cpupool_id;
>>>>> 
>>>>> This could do with a comment explaining default behavior. In particular
>>>>> I wonder what 0 means: Looking at cpupool_destroy() I can't see that it
>>>>> would be impossible to delete pool 0 (but there may of course be
>>>>> reasons elsewhere, e.g. preventing pool 0 to ever go empty) - Jürgen?
>>>>> Yet if pool 0 can be removed, zero being passed in here should imo not
>>>>> lead to failure of VM creation. Otoh I understand that this would
>>>>> already happen ahead of your change, preventing of which would
>>>>> apparently possible only via passing CPUPOOLID_NONE here.
>>>> 
>>>> Pool-0 can’t be emptied because Dom0 is sitting there (the patch is 
>>>> modifying
>>>> cpupool_id only for DomUs).
>>> 
>>> But we're talking about dom0less as per the subject of the patch here.
>> 
>> Domains started using dom0less feature are not privileged and can’t do any 
>> operation
>> on cpu pools, that’s why I thought about Dom0.
> 
> It's all a matter of XSM policy what a domain may or may not be able
> to carry out.

Yes you are right, however I didn’t see so far this use case with a domU and 
the tool stack,
probably because it would need also xenstore etc… I’m aware that there is some 
work going
on to enable it also for dom0less domUs, so my question is:

Do you see this as a blocker for this patch? Are you ok if I send this patch 
with just the comment
below or in your opinion this patch requires some other work?

> 
>>>> I thought the name was self explanatory, but if I have to put a comment, 
>>>> would
>>>> It work something like that:
>>>> 
>>>> /* Cpupool id where the domain will be assigned on creation */
>>> 
>>> I don't view this kind of comment as necessary. I was really after
>>> calling out default behavior, along the lines of "0 to disable" that
>>> you can see in patch context.
>> 
>> Ok, could this work?
>> 
>> /* Domain cpupool id on creation. Default 0 as Pool-0 is always present. */
> 
> Hmm, I may have misguided you by talking about "default". There's no
> default here, as it's the caller's responsibility to set the field,
> and what's there will be used. Maybe "CPU pool to use; specify 0
> unless a specific existing pool is to be used".

Thank you, I will use it and update the patch.

> 
> Jan