With CPU hotplug sysctls implemented on Arm it becomes useful to have a
tool for calling them.
According to the commit history it seems that putting hptool under
config MIGRATE was a measure to fix IA64 build. As IA64 is no longer
supported it can now be brought back. So build it unconditionally.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
---
v6->v7:
* no changes
v5->v6:
* don't change order in Makefile
v4->v5:
* make hptool always build
v3->v4:
* no changes
v2->v3:
* no changes
v1->v2:
* switch to configure from legacy config
---
tools/libs/guest/Makefile.common | 2 +-
tools/misc/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common
index b928a4a246..03dfcee7fa 100644
--- a/tools/libs/guest/Makefile.common
+++ b/tools/libs/guest/Makefile.common
@@ -7,6 +7,7 @@ OBJS-y += xg_private.o
OBJS-y += xg_domain.o
OBJS-y += xg_suspend.o
OBJS-y += xg_resume.o
+OBJS-y += xg_offline_page.o
ifeq ($(CONFIG_MIGRATE),y)
OBJS-y += xg_sr_common.o
OBJS-$(CONFIG_X86) += xg_sr_common_x86.o
@@ -17,7 +18,6 @@ OBJS-$(CONFIG_X86) += xg_sr_save_x86_pv.o
OBJS-$(CONFIG_X86) += xg_sr_save_x86_hvm.o
OBJS-y += xg_sr_restore.o
OBJS-y += xg_sr_save.o
-OBJS-y += xg_offline_page.o
else
OBJS-y += xg_nomigrate.o
endif
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 6ee783f43e..5a206133f7 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -16,7 +16,7 @@ INSTALL_BIN += xencov_split
INSTALL_BIN += $(INSTALL_BIN-y)
# Everything to be installed in regular sbin/
-INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
+INSTALL_SBIN += xen-hptool
INSTALL_SBIN-$(CONFIG_X86) += xen-hvmcrash
INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx
INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
--
2.51.2On 30.03.2026 13:59, Mykyta Poturai wrote: > With CPU hotplug sysctls implemented on Arm it becomes useful to have a > tool for calling them. > > According to the commit history it seems that putting hptool under > config MIGRATE was a measure to fix IA64 build. As IA64 is no longer > supported it can now be brought back. So build it unconditionally. > > Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com> > --- > v6->v7: > * no changes > > v5->v6: > * don't change order in Makefile > > v4->v5: > * make hptool always build > > v3->v4: > * no changes > > v2->v3: > * no changes > > v1->v2: > * switch to configure from legacy config > --- > tools/libs/guest/Makefile.common | 2 +- > tools/misc/Makefile | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common > index b928a4a246..03dfcee7fa 100644 > --- a/tools/libs/guest/Makefile.common > +++ b/tools/libs/guest/Makefile.common > @@ -7,6 +7,7 @@ OBJS-y += xg_private.o > OBJS-y += xg_domain.o > OBJS-y += xg_suspend.o > OBJS-y += xg_resume.o > +OBJS-y += xg_offline_page.o > ifeq ($(CONFIG_MIGRATE),y) > OBJS-y += xg_sr_common.o > OBJS-$(CONFIG_X86) += xg_sr_common_x86.o > @@ -17,7 +18,6 @@ OBJS-$(CONFIG_X86) += xg_sr_save_x86_pv.o > OBJS-$(CONFIG_X86) += xg_sr_save_x86_hvm.o > OBJS-y += xg_sr_restore.o > OBJS-y += xg_sr_save.o > -OBJS-y += xg_offline_page.o > else > OBJS-y += xg_nomigrate.o > endif This looks wrong to me. There are x86-specifics in that file, which shouldn't be built on Arm. And the name of the file also doesn't indicate any relation to CPU management. Jan
On 3/30/26 15:32, Jan Beulich wrote: > On 30.03.2026 13:59, Mykyta Poturai wrote: >> With CPU hotplug sysctls implemented on Arm it becomes useful to have a >> tool for calling them. >> >> According to the commit history it seems that putting hptool under >> config MIGRATE was a measure to fix IA64 build. As IA64 is no longer >> supported it can now be brought back. So build it unconditionally. >> >> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com> >> --- >> v6->v7: >> * no changes >> >> v5->v6: >> * don't change order in Makefile >> >> v4->v5: >> * make hptool always build >> >> v3->v4: >> * no changes >> >> v2->v3: >> * no changes >> >> v1->v2: >> * switch to configure from legacy config >> --- >> tools/libs/guest/Makefile.common | 2 +- >> tools/misc/Makefile | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common >> index b928a4a246..03dfcee7fa 100644 >> --- a/tools/libs/guest/Makefile.common >> +++ b/tools/libs/guest/Makefile.common >> @@ -7,6 +7,7 @@ OBJS-y += xg_private.o >> OBJS-y += xg_domain.o >> OBJS-y += xg_suspend.o >> OBJS-y += xg_resume.o >> +OBJS-y += xg_offline_page.o >> ifeq ($(CONFIG_MIGRATE),y) >> OBJS-y += xg_sr_common.o >> OBJS-$(CONFIG_X86) += xg_sr_common_x86.o >> @@ -17,7 +18,6 @@ OBJS-$(CONFIG_X86) += xg_sr_save_x86_pv.o >> OBJS-$(CONFIG_X86) += xg_sr_save_x86_hvm.o >> OBJS-y += xg_sr_restore.o >> OBJS-y += xg_sr_save.o >> -OBJS-y += xg_offline_page.o >> else >> OBJS-y += xg_nomigrate.o >> endif > > This looks wrong to me. There are x86-specifics in that file, which shouldn't > be built on Arm. And the name of the file also doesn't indicate any relation > to CPU management. > > Jan xen-hptool requires xg_offline_page as it has both CPU and memory hotplug commands. Without building xg_offline_page it fails with xen-hptool: symbol lookup error: xen-hptool: undefined symbol: xc_mark_page_offline, version libxenguest_4.22.0 when trying to do memory ops. Is it an acceptable behavior? If so I guess we can build xg_offline page only on x86. -- Mykyta
On 15.04.2026 16:51, Mykyta Poturai wrote: > On 3/30/26 15:32, Jan Beulich wrote: >> On 30.03.2026 13:59, Mykyta Poturai wrote: >>> With CPU hotplug sysctls implemented on Arm it becomes useful to have a >>> tool for calling them. >>> >>> According to the commit history it seems that putting hptool under >>> config MIGRATE was a measure to fix IA64 build. As IA64 is no longer >>> supported it can now be brought back. So build it unconditionally. >>> >>> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com> >>> --- >>> v6->v7: >>> * no changes >>> >>> v5->v6: >>> * don't change order in Makefile >>> >>> v4->v5: >>> * make hptool always build >>> >>> v3->v4: >>> * no changes >>> >>> v2->v3: >>> * no changes >>> >>> v1->v2: >>> * switch to configure from legacy config >>> --- >>> tools/libs/guest/Makefile.common | 2 +- >>> tools/misc/Makefile | 2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common >>> index b928a4a246..03dfcee7fa 100644 >>> --- a/tools/libs/guest/Makefile.common >>> +++ b/tools/libs/guest/Makefile.common >>> @@ -7,6 +7,7 @@ OBJS-y += xg_private.o >>> OBJS-y += xg_domain.o >>> OBJS-y += xg_suspend.o >>> OBJS-y += xg_resume.o >>> +OBJS-y += xg_offline_page.o >>> ifeq ($(CONFIG_MIGRATE),y) >>> OBJS-y += xg_sr_common.o >>> OBJS-$(CONFIG_X86) += xg_sr_common_x86.o >>> @@ -17,7 +18,6 @@ OBJS-$(CONFIG_X86) += xg_sr_save_x86_pv.o >>> OBJS-$(CONFIG_X86) += xg_sr_save_x86_hvm.o >>> OBJS-y += xg_sr_restore.o >>> OBJS-y += xg_sr_save.o >>> -OBJS-y += xg_offline_page.o >>> else >>> OBJS-y += xg_nomigrate.o >>> endif >> >> This looks wrong to me. There are x86-specifics in that file, which shouldn't >> be built on Arm. And the name of the file also doesn't indicate any relation >> to CPU management. > > xen-hptool requires xg_offline_page as it has both CPU and memory > hotplug commands. Without building xg_offline_page it fails with > > xen-hptool: symbol lookup error: xen-hptool: undefined symbol: > xc_mark_page_offline, version libxenguest_4.22.0 > > when trying to do memory ops. > > Is it an acceptable behavior? I don't think so, no. The tool wouldn't, aiui, load at all then if built with "bindnow" enabled. > If so I guess we can build xg_offline page only on x86. We still need to, imo. But the tool still needs to be usable no matter how specifically it is built. It should avoid referencing xg_offline_page.c functions when built for non-x86. Jan
On 4/16/26 09:49, Jan Beulich wrote: > On 15.04.2026 16:51, Mykyta Poturai wrote: >> On 3/30/26 15:32, Jan Beulich wrote: >>> On 30.03.2026 13:59, Mykyta Poturai wrote: >>>> With CPU hotplug sysctls implemented on Arm it becomes useful to have a >>>> tool for calling them. >>>> >>>> According to the commit history it seems that putting hptool under >>>> config MIGRATE was a measure to fix IA64 build. As IA64 is no longer >>>> supported it can now be brought back. So build it unconditionally. >>>> >>>> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com> >>>> --- >>>> v6->v7: >>>> * no changes >>>> >>>> v5->v6: >>>> * don't change order in Makefile >>>> >>>> v4->v5: >>>> * make hptool always build >>>> >>>> v3->v4: >>>> * no changes >>>> >>>> v2->v3: >>>> * no changes >>>> >>>> v1->v2: >>>> * switch to configure from legacy config >>>> --- >>>> tools/libs/guest/Makefile.common | 2 +- >>>> tools/misc/Makefile | 2 +- >>>> 2 files changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common >>>> index b928a4a246..03dfcee7fa 100644 >>>> --- a/tools/libs/guest/Makefile.common >>>> +++ b/tools/libs/guest/Makefile.common >>>> @@ -7,6 +7,7 @@ OBJS-y += xg_private.o >>>> OBJS-y += xg_domain.o >>>> OBJS-y += xg_suspend.o >>>> OBJS-y += xg_resume.o >>>> +OBJS-y += xg_offline_page.o >>>> ifeq ($(CONFIG_MIGRATE),y) >>>> OBJS-y += xg_sr_common.o >>>> OBJS-$(CONFIG_X86) += xg_sr_common_x86.o >>>> @@ -17,7 +18,6 @@ OBJS-$(CONFIG_X86) += xg_sr_save_x86_pv.o >>>> OBJS-$(CONFIG_X86) += xg_sr_save_x86_hvm.o >>>> OBJS-y += xg_sr_restore.o >>>> OBJS-y += xg_sr_save.o >>>> -OBJS-y += xg_offline_page.o >>>> else >>>> OBJS-y += xg_nomigrate.o >>>> endif >>> >>> This looks wrong to me. There are x86-specifics in that file, which shouldn't >>> be built on Arm. And the name of the file also doesn't indicate any relation >>> to CPU management. >> >> xen-hptool requires xg_offline_page as it has both CPU and memory >> hotplug commands. Without building xg_offline_page it fails with >> >> xen-hptool: symbol lookup error: xen-hptool: undefined symbol: >> xc_mark_page_offline, version libxenguest_4.22.0 >> >> when trying to do memory ops. >> >> Is it an acceptable behavior? > > I don't think so, no. The tool wouldn't, aiui, load at all then if built with > "bindnow" enabled. > >> If so I guess we can build xg_offline page only on x86. > > We still need to, imo. But the tool still needs to be usable no matter how > specifically it is built. It should avoid referencing xg_offline_page.c > functions when built for non-x86. > > Jan As I understand, the usage of arch-specific compile time checks is heavily discouraged in tools. So I don’t think it would be approved by tools maintainers. Do we really need to omit this file if memory ops are already getting blocked by Xen on Arm anyway? -- Mykyta
On Thu, Apr 16, 2026 at 08:22:32AM +0000, Mykyta Poturai wrote: > On 4/16/26 09:49, Jan Beulich wrote: > > On 15.04.2026 16:51, Mykyta Poturai wrote: > >> On 3/30/26 15:32, Jan Beulich wrote: > >>> This looks wrong to me. There are x86-specifics in that file, which shouldn't > >>> be built on Arm. And the name of the file also doesn't indicate any relation > >>> to CPU management. > >> > >> xen-hptool requires xg_offline_page as it has both CPU and memory > >> hotplug commands. Without building xg_offline_page it fails with > >> > >> xen-hptool: symbol lookup error: xen-hptool: undefined symbol: > >> xc_mark_page_offline, version libxenguest_4.22.0 > >> > >> when trying to do memory ops. > >> > >> Is it an acceptable behavior? > > > > I don't think so, no. The tool wouldn't, aiui, load at all then if built with > > "bindnow" enabled. > > > >> If so I guess we can build xg_offline page only on x86. > > > > We still need to, imo. But the tool still needs to be usable no matter how > > specifically it is built. It should avoid referencing xg_offline_page.c > > functions when built for non-x86. > > As I understand, the usage of arch-specific compile time checks is > heavily discouraged in tools. So I don’t think it would be approved by > tools maintainers. Do we really need to omit this file if memory ops are > already getting blocked by Xen on Arm anyway? So you are trying to modify a library and introduced untested functionality just to be able to build a different tool? I don't think that a good idea especially in this case where it's more than just glue code between a binary and xen. We could change the library to provide the missing symbols, but it is probably best to keep it that way for now. So, how about changing `xen-hptool` to have reduced functionality on other platform, and keep the 'mem-*' command on x86 only? You could move the function that implement the 'mem-*' command into a separate file, that compile only on x86 (or more specifically when CONFIG_MIGRATE is set) and just have a "#if defined(__i386__) || defined(__x86_64__)" in the `main_options` array. They are compile-time arch-specific check everywhere in tools. Arch specific are often implemented in separated source file, this mean we can limit the #ifdefs to a minimum and keep the code readable. Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
On 4/29/26 17:33, Anthony PERARD wrote: > On Thu, Apr 16, 2026 at 08:22:32AM +0000, Mykyta Poturai wrote: >> On 4/16/26 09:49, Jan Beulich wrote: >>> On 15.04.2026 16:51, Mykyta Poturai wrote: >>>> On 3/30/26 15:32, Jan Beulich wrote: >>>>> This looks wrong to me. There are x86-specifics in that file, which shouldn't >>>>> be built on Arm. And the name of the file also doesn't indicate any relation >>>>> to CPU management. >>>> >>>> xen-hptool requires xg_offline_page as it has both CPU and memory >>>> hotplug commands. Without building xg_offline_page it fails with >>>> >>>> xen-hptool: symbol lookup error: xen-hptool: undefined symbol: >>>> xc_mark_page_offline, version libxenguest_4.22.0 >>>> >>>> when trying to do memory ops. >>>> >>>> Is it an acceptable behavior? >>> >>> I don't think so, no. The tool wouldn't, aiui, load at all then if built with >>> "bindnow" enabled. >>> >>>> If so I guess we can build xg_offline page only on x86. >>> >>> We still need to, imo. But the tool still needs to be usable no matter how >>> specifically it is built. It should avoid referencing xg_offline_page.c >>> functions when built for non-x86. >> >> As I understand, the usage of arch-specific compile time checks is >> heavily discouraged in tools. So I don’t think it would be approved by >> tools maintainers. Do we really need to omit this file if memory ops are >> already getting blocked by Xen on Arm anyway? > > So you are trying to modify a library and introduced untested > functionality just to be able to build a different tool? I don't think > that a good idea especially in this case where it's more than just glue > code between a binary and xen. > > We could change the library to provide the missing symbols, but it is > probably best to keep it that way for now. > > So, how about changing `xen-hptool` to have reduced functionality on > other platform, and keep the 'mem-*' command on x86 only? You could move > the function that implement the 'mem-*' command into a separate file, > that compile only on x86 (or more specifically when CONFIG_MIGRATE is > set) and just have a "#if defined(__i386__) || defined(__x86_64__)" in > the `main_options` array. > > They are compile-time arch-specific check everywhere in tools. Arch > specific are often implemented in separated source file, this mean we > can limit the #ifdefs to a minimum and keep the code readable. > > Thanks, > > Should I also do the same thing for SMT operations? -- Mykyta
On Wed, May 06, 2026 at 08:52:29AM +0000, Mykyta Poturai wrote: > On 4/29/26 17:33, Anthony PERARD wrote: > > So you are trying to modify a library and introduced untested > > functionality just to be able to build a different tool? I don't think > > that a good idea especially in this case where it's more than just glue > > code between a binary and xen. > > > > We could change the library to provide the missing symbols, but it is > > probably best to keep it that way for now. > > > > So, how about changing `xen-hptool` to have reduced functionality on > > other platform, and keep the 'mem-*' command on x86 only? You could move > > the function that implement the 'mem-*' command into a separate file, > > that compile only on x86 (or more specifically when CONFIG_MIGRATE is > > set) and just have a "#if defined(__i386__) || defined(__x86_64__)" in > > the `main_options` array. > > > > They are compile-time arch-specific check everywhere in tools. Arch > > specific are often implemented in separated source file, this mean we > > can limit the #ifdefs to a minimum and keep the code readable. > > Should I also do the same thing for SMT operations? I guess it wouldn't hurt they are x86 only. So yes, looks like a good idea to do it for the smt op as well. Cheers, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
On 16.04.2026 10:22, Mykyta Poturai wrote: > On 4/16/26 09:49, Jan Beulich wrote: >> On 15.04.2026 16:51, Mykyta Poturai wrote: >>> On 3/30/26 15:32, Jan Beulich wrote: >>>> On 30.03.2026 13:59, Mykyta Poturai wrote: >>>>> With CPU hotplug sysctls implemented on Arm it becomes useful to have a >>>>> tool for calling them. >>>>> >>>>> According to the commit history it seems that putting hptool under >>>>> config MIGRATE was a measure to fix IA64 build. As IA64 is no longer >>>>> supported it can now be brought back. So build it unconditionally. >>>>> >>>>> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com> >>>>> --- >>>>> v6->v7: >>>>> * no changes >>>>> >>>>> v5->v6: >>>>> * don't change order in Makefile >>>>> >>>>> v4->v5: >>>>> * make hptool always build >>>>> >>>>> v3->v4: >>>>> * no changes >>>>> >>>>> v2->v3: >>>>> * no changes >>>>> >>>>> v1->v2: >>>>> * switch to configure from legacy config >>>>> --- >>>>> tools/libs/guest/Makefile.common | 2 +- >>>>> tools/misc/Makefile | 2 +- >>>>> 2 files changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common >>>>> index b928a4a246..03dfcee7fa 100644 >>>>> --- a/tools/libs/guest/Makefile.common >>>>> +++ b/tools/libs/guest/Makefile.common >>>>> @@ -7,6 +7,7 @@ OBJS-y += xg_private.o >>>>> OBJS-y += xg_domain.o >>>>> OBJS-y += xg_suspend.o >>>>> OBJS-y += xg_resume.o >>>>> +OBJS-y += xg_offline_page.o >>>>> ifeq ($(CONFIG_MIGRATE),y) >>>>> OBJS-y += xg_sr_common.o >>>>> OBJS-$(CONFIG_X86) += xg_sr_common_x86.o >>>>> @@ -17,7 +18,6 @@ OBJS-$(CONFIG_X86) += xg_sr_save_x86_pv.o >>>>> OBJS-$(CONFIG_X86) += xg_sr_save_x86_hvm.o >>>>> OBJS-y += xg_sr_restore.o >>>>> OBJS-y += xg_sr_save.o >>>>> -OBJS-y += xg_offline_page.o >>>>> else >>>>> OBJS-y += xg_nomigrate.o >>>>> endif >>>> >>>> This looks wrong to me. There are x86-specifics in that file, which shouldn't >>>> be built on Arm. And the name of the file also doesn't indicate any relation >>>> to CPU management. >>> >>> xen-hptool requires xg_offline_page as it has both CPU and memory >>> hotplug commands. Without building xg_offline_page it fails with >>> >>> xen-hptool: symbol lookup error: xen-hptool: undefined symbol: >>> xc_mark_page_offline, version libxenguest_4.22.0 >>> >>> when trying to do memory ops. >>> >>> Is it an acceptable behavior? >> >> I don't think so, no. The tool wouldn't, aiui, load at all then if built with >> "bindnow" enabled. >> >>> If so I guess we can build xg_offline page only on x86. >> >> We still need to, imo. But the tool still needs to be usable no matter how >> specifically it is built. It should avoid referencing xg_offline_page.c >> functions when built for non-x86. > > As I understand, the usage of arch-specific compile time checks is > heavily discouraged in tools. So I don’t think it would be approved by > tools maintainers. Do we really need to omit this file if memory ops are > already getting blocked by Xen on Arm anyway? Nothing I can answer in a way that's definitive for your purpose. As you say, the final word here is with Anthony. I've voiced my opinion. Jan
© 2016 - 2026 Red Hat, Inc.