> On 18 May 2022, at 11:12, Andrew Cooper <andrew.coop...@citrix.com> wrote: > > On 18/05/2022 10:51, Edwin Torok wrote: >>> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml >>> index 7503031d8f61..8eab6f60eb14 100644 >>> --- a/tools/ocaml/libs/xc/xenctrl.ml >>> +++ b/tools/ocaml/libs/xc/xenctrl.ml >>> @@ -85,6 +85,7 @@ type domctl_create_config = >>> max_grant_frames: int; >>> max_maptrack_frames: int; >>> max_grant_version: int; >>> + cpupool_id: int32; >> What are the valid values for a CPU pool id, in particular what value should >> be passed here to get back the behaviour prior to these changes in Xen? >> (i.e. would it be cpu pool id 0 or -1 if cpu pools aren't otherwise >> explicitly configured on the system) > > cpupools are a non-optional construct in Xen. > > By default, one cpupool exists, with the id 0, using the default > scheduler covering all pCPUs, and dom0 is constructed in this cpupool. > > Passing 0 here is the backwards compatible option. > > And on that note, Luca, you ought to patch xl/libxl to apply the pool= > setting directly during domain create, rather than depending on cpupool > 0 existing and moving the domain later.
Is it an enhancement or a bug fix? From what I know, please correct me if I’m wrong, cpupool0 Is always present, so there won’t be problem on assuming its existence > > ~Andrew
