Message ID | 20220408084517.33082-6-luca.fancellu@arm.com (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | Boot time cpupools | expand |
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
> 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 >
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
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
> 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
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
> 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
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
> 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
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 --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__ */