> On 11 Apr 2022, at 10:08, Jan Beulich <jbeul...@suse.com> wrote:
>
> On 11.04.2022 10:54, Luca Fancellu wrote:
>>> On 8 Apr 2022, at 13:10, Jan Beulich <jbeul...@suse.com> wrote:
>>> On 08.04.2022 13:15, Luca Fancellu wrote:
>>>>> On 8 Apr 2022, at 11:24, Jan Beulich <jbeul...@suse.com> wrote:
>>>>> On 08.04.2022 11:39, Luca Fancellu wrote:
>>>>>>> On 8 Apr 2022, at 10:10, Jan Beulich <jbeul...@suse.com> 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?
>
> Agreement looks to be that there should be precautionary code added
> to prevent the deleting of pool 0. This imo wants to be a prereq
> change to the one here.
Since we have the requirement of having cpu0 in pool-0, I’m thinking about a
check to don’t allow
Cpu0 to be removed from pool-0, that will cover also the destroy case because
we can’t destroy
a cpupool that is not empty.
In your opinion is it ok to proceed with a separate patch as prereq work having
this change?
>
> Jan
