diff mbox series

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

Message ID 20220408084517.33082-6-luca.fancellu@arm.com (mailing list archive)
State Superseded
Headers show
Series Boot time cpupools | expand

Commit Message

Luca Fancellu April 8, 2022, 8:45 a.m. UTC
Introduce domain-cpupool property of a xen,domain device tree node,
that specifies the cpupool device tree handle of a xen,cpupool node
that identifies a cpupool created at boot time where the guest will
be assigned on creation.

Add member to the xen_domctl_createdomain public interface so the
XEN_DOMCTL_INTERFACE_VERSION version is bumped.

Add public function to retrieve a pool id from the device tree
cpupool node.

Update documentation about the property.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v6:
- no changes
Changes in v5:
- no changes
Changes in v4:
- no changes
- add R-by
Changes in v3:
- Use explicitely sized integer for struct xen_domctl_createdomain
  cpupool_id member. (Stefano)
- Changed code due to previous commit code changes
Changes in v2:
- Moved cpupool_id from arch specific to common part (Juergen)
- Implemented functions to retrieve the cpupool id from the
  cpupool dtb node.
---
 docs/misc/arm/device-tree/booting.txt |  5 +++++
 xen/arch/arm/domain_build.c           | 14 +++++++++++++-
 xen/common/boot_cpupools.c            | 24 ++++++++++++++++++++++++
 xen/common/domain.c                   |  2 +-
 xen/include/public/domctl.h           |  4 +++-
 xen/include/xen/sched.h               |  9 +++++++++
 6 files changed, 55 insertions(+), 3 deletions(-)

Comments

Jan Beulich April 8, 2022, 9:10 a.m. UTC | #1
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.

Jan
Luca Fancellu April 8, 2022, 9:39 a.m. UTC | #2
> On 8 Apr 2022, at 10:10, Jan Beulich <jbeulich@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.

Hi Jan,

Pool-0 can’t be emptied because Dom0 is sitting there (the patch is modifying
cpupool_id only for DomUs).

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 */


> 
> Jan
>
Jan Beulich April 8, 2022, 10:24 a.m. UTC | #3
On 08.04.2022 11:39, Luca Fancellu wrote:
> 
> 
>> On 8 Apr 2022, at 10:10, Jan Beulich <jbeulich@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.

> 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.

Jan
Jürgen Groß April 8, 2022, 10:37 a.m. UTC | #4
On 08.04.22 11:10, Jan Beulich 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?

Yes, I think destroying of cpupool 0 in a dom0less system should be
prohibited, assuming there is a control domain being able to destroy
a cpupool in a dom0less system.

Main reason is that cpupool 0 has a special role e.g. during domain
destruction (see domain_kill()) and for cpu hotplug operations.


Juergen
Luca Fancellu April 8, 2022, 11:15 a.m. UTC | #5
> On 8 Apr 2022, at 11:24, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 08.04.2022 11:39, Luca Fancellu wrote:
>> 
>> 
>>> On 8 Apr 2022, at 10:10, Jan Beulich <jbeulich@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.

> 
>> 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. */

> 
> Jan
Jan Beulich April 8, 2022, 12:10 p.m. UTC | #6
On 08.04.2022 13:15, Luca Fancellu wrote:
> 
> 
>> On 8 Apr 2022, at 11:24, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 08.04.2022 11:39, Luca Fancellu wrote:
>>>
>>>
>>>> On 8 Apr 2022, at 10:10, Jan Beulich <jbeulich@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.

>>> 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".

Jan
Luca Fancellu April 11, 2022, 8:54 a.m. UTC | #7
> On 8 Apr 2022, at 13:10, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 08.04.2022 13:15, Luca Fancellu wrote:
>> 
>> 
>>> On 8 Apr 2022, at 11:24, Jan Beulich <jbeulich@suse.com> wrote:
>>> 
>>> On 08.04.2022 11:39, Luca Fancellu wrote:
>>>> 
>>>> 
>>>>> On 8 Apr 2022, at 10:10, Jan Beulich <jbeulich@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?

> 
>>>> 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
Jan Beulich April 11, 2022, 9:08 a.m. UTC | #8
On 11.04.2022 10:54, Luca Fancellu wrote:
>> On 8 Apr 2022, at 13:10, Jan Beulich <jbeulich@suse.com> wrote:
>> On 08.04.2022 13:15, Luca Fancellu wrote:
>>>> On 8 Apr 2022, at 11:24, Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 08.04.2022 11:39, Luca Fancellu wrote:
>>>>>> On 8 Apr 2022, at 10:10, Jan Beulich <jbeulich@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.

Jan
Luca Fancellu April 11, 2022, 10:20 a.m. UTC | #9
> On 11 Apr 2022, at 10:08, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 11.04.2022 10:54, Luca Fancellu wrote:
>>> On 8 Apr 2022, at 13:10, Jan Beulich <jbeulich@suse.com> wrote:
>>> On 08.04.2022 13:15, Luca Fancellu wrote:
>>>>> On 8 Apr 2022, at 11:24, Jan Beulich <jbeulich@suse.com> wrote:
>>>>> On 08.04.2022 11:39, Luca Fancellu wrote:
>>>>>>> On 8 Apr 2022, at 10:10, Jan Beulich <jbeulich@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
Jan Beulich April 11, 2022, 10:23 a.m. UTC | #10
On 11.04.2022 12:20, Luca Fancellu wrote:
> 
> 
>> On 11 Apr 2022, at 10:08, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 11.04.2022 10:54, Luca Fancellu wrote:
>>>> On 8 Apr 2022, at 13:10, Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 08.04.2022 13:15, Luca Fancellu wrote:
>>>>>> On 8 Apr 2022, at 11:24, Jan Beulich <jbeulich@suse.com> wrote:
>>>>>> On 08.04.2022 11:39, Luca Fancellu wrote:
>>>>>>>> On 8 Apr 2022, at 10:10, Jan Beulich <jbeulich@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?

Well, I did already say so (see context above).

Jan
diff mbox series

Patch

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index a94125394e35..7b4a29a2c293 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -188,6 +188,11 @@  with the following properties:
     An empty property to request the memory of the domain to be
     direct-map (guest physical address == physical address).
 
+- domain-cpupool
+
+    Optional. Handle to a xen,cpupool device tree node that identifies the
+    cpupool where the guest will be started at boot.
+
 Under the "xen,domain" compatible node, one or more sub-nodes are present
 for the DomU kernel and ramdisk.
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8be01678de05..9c67a483d4a4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3172,7 +3172,8 @@  static int __init construct_domU(struct domain *d,
 void __init create_domUs(void)
 {
     struct dt_device_node *node;
-    const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+    const struct dt_device_node *cpupool_node,
+                                *chosen = dt_find_node_by_path("/chosen");
 
     BUG_ON(chosen == NULL);
     dt_for_each_child_node(chosen, node)
@@ -3241,6 +3242,17 @@  void __init create_domUs(void)
                                          vpl011_virq - 32 + 1);
         }
 
+        /* Get the optional property domain-cpupool */
+        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
+        if ( cpupool_node )
+        {
+            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
+            if ( pool_id < 0 )
+                panic("Error getting cpupool id from domain-cpupool (%d)\n",
+                      pool_id);
+            d_cfg.cpupool_id = pool_id;
+        }
+
         /*
          * The variable max_init_domid is initialized with zero, so here it's
          * very important to use the pre-increment operator to call
diff --git a/xen/common/boot_cpupools.c b/xen/common/boot_cpupools.c
index 9429a5025fc4..240bae4cebb8 100644
--- a/xen/common/boot_cpupools.c
+++ b/xen/common/boot_cpupools.c
@@ -22,6 +22,8 @@  static unsigned int __initdata next_pool_id;
 
 #define BTCPUPOOLS_DT_NODE_NO_REG     (-1)
 #define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
+#define BTCPUPOOLS_DT_WRONG_NODE      (-3)
+#define BTCPUPOOLS_DT_CORRUPTED_NODE  (-4)
 
 static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
 {
@@ -56,6 +58,28 @@  get_logical_cpu_from_cpu_node(const struct dt_device_node *cpu_node)
     return cpu_num;
 }
 
+int __init btcpupools_get_domain_pool_id(const struct dt_device_node *node)
+{
+    const struct dt_device_node *phandle_node;
+    int cpu_num;
+
+    if ( !dt_device_is_compatible(node, "xen,cpupool") )
+        return BTCPUPOOLS_DT_WRONG_NODE;
+    /*
+     * Get first cpu listed in the cpupool, from its reg it's possible to
+     * retrieve the cpupool id.
+     */
+    phandle_node = dt_parse_phandle(node, "cpupool-cpus", 0);
+    if ( !phandle_node )
+        return BTCPUPOOLS_DT_CORRUPTED_NODE;
+
+    cpu_num = get_logical_cpu_from_cpu_node(phandle_node);
+    if ( cpu_num < 0 )
+        return cpu_num;
+
+    return pool_cpu_map[cpu_num];
+}
+
 static int __init check_and_get_sched_id(const char* scheduler_name)
 {
     int sched_id = sched_get_id_by_name(scheduler_name);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 351029f8b239..0827400f4f49 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -698,7 +698,7 @@  struct domain *domain_create(domid_t domid,
         if ( !d->pbuf )
             goto fail;
 
-        if ( (err = sched_init_domain(d, 0)) != 0 )
+        if ( (err = sched_init_domain(d, config->cpupool_id)) != 0 )
             goto fail;
 
         if ( (err = late_hwdom_init(d)) != 0 )
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index b85e6170b0aa..2f4cf56f438d 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -38,7 +38,7 @@ 
 #include "hvm/save.h"
 #include "memory.h"
 
-#define XEN_DOMCTL_INTERFACE_VERSION 0x00000014
+#define XEN_DOMCTL_INTERFACE_VERSION 0x00000015
 
 /*
  * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
@@ -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;
+
     struct xen_arch_domainconfig arch;
 };
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 453e98f1cba8..b62315ad5e5d 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1182,6 +1182,7 @@  void arch_do_physinfo(struct xen_sysctl_physinfo *pi);
 void btcpupools_allocate_pools(void);
 unsigned int btcpupools_get_cpupool_id(unsigned int cpu);
 void btcpupools_dtb_parse(void);
+int btcpupools_get_domain_pool_id(const struct dt_device_node *node);
 
 #else /* !CONFIG_BOOT_TIME_CPUPOOLS */
 static inline void btcpupools_allocate_pools(void) {}
@@ -1190,6 +1191,14 @@  static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
 {
     return 0;
 }
+#ifdef CONFIG_HAS_DEVICE_TREE
+static inline int
+btcpupools_get_domain_pool_id(const struct dt_device_node *node)
+{
+    return 0;
+}
+#endif
+
 #endif
 
 #endif /* __SCHED_H__ */