... to a dedicated subdir of x86's private lib/ sub-tree.
For the CPU policy harnesses and libxenguest use $(lib-y) as set by the
new Makefile.common, whereas for the emulator harnesses stick to building
just cpuid.o for the time being.
Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.
---
tools/fuzz/cpu-policy/Makefile | 7 +++++--
tools/fuzz/x86_instruction_emulator/Makefile | 2 +-
tools/libs/guest/Makefile.common | 7 +++++--
tools/tests/cpu-policy/Makefile | 7 +++++--
tools/tests/x86_emulator/Makefile | 2 +-
xen/arch/x86/arch.mk | 1 +
xen/arch/x86/lib/Makefile | 2 ++
xen/arch/x86/lib/cpu-policy/Makefile | 1 +
xen/arch/x86/lib/cpu-policy/Makefile.common | 3 +++
xen/{lib/x86 => arch/x86/lib/cpu-policy}/cpuid.c | 0
xen/{lib/x86 => arch/x86/lib/cpu-policy}/msr.c | 0
xen/{lib/x86 => arch/x86/lib/cpu-policy}/policy.c | 0
xen/{lib/x86 => arch/x86/lib/cpu-policy}/private.h | 0
xen/lib/Makefile | 2 --
xen/lib/x86/Makefile | 3 ---
15 files changed, 24 insertions(+), 13 deletions(-)
create mode 100644 xen/arch/x86/lib/cpu-policy/Makefile
create mode 100644 xen/arch/x86/lib/cpu-policy/Makefile.common
rename xen/{lib/x86 => arch/x86/lib/cpu-policy}/cpuid.c (100%)
rename xen/{lib/x86 => arch/x86/lib/cpu-policy}/msr.c (100%)
rename xen/{lib/x86 => arch/x86/lib/cpu-policy}/policy.c (100%)
rename xen/{lib/x86 => arch/x86/lib/cpu-policy}/private.h (100%)
delete mode 100644 xen/lib/x86/Makefile
diff --git a/tools/fuzz/cpu-policy/Makefile b/tools/fuzz/cpu-policy/Makefile
index 6e7743e0aa12..76ecf20e8dbd 100644
--- a/tools/fuzz/cpu-policy/Makefile
+++ b/tools/fuzz/cpu-policy/Makefile
@@ -20,9 +20,12 @@ install: all
CFLAGS += $(CFLAGS_xeninclude) -D__XEN_TOOLS__
CFLAGS += $(APPEND_CFLAGS) -Og
-vpath %.c ../../../xen/lib/x86
+vpath %.c $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy
-afl-policy-fuzzer: afl-policy-fuzzer.o msr.o cpuid.o
+lib-y :=
+include $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy/Makefile.common
+
+afl-policy-fuzzer: afl-policy-fuzzer.o $(lib-y)
$(CC) $(CFLAGS) $^ -o $@
-include $(DEPS_INCLUDE)
diff --git a/tools/fuzz/x86_instruction_emulator/Makefile b/tools/fuzz/x86_instruction_emulator/Makefile
index d104b15f4fbf..4e4877a20322 100644
--- a/tools/fuzz/x86_instruction_emulator/Makefile
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -21,7 +21,7 @@ vpath %.h ../../tests/x86_emulator
CFLAGS += -iquote ../../tests/x86_emulator
# Add libx86 to the build
-vpath %.c $(XEN_ROOT)/xen/lib/x86
+vpath %.c $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy
x86_emulate:
mkdir -p $@
diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common
index a026a2f662b0..b928a4a246a9 100644
--- a/tools/libs/guest/Makefile.common
+++ b/tools/libs/guest/Makefile.common
@@ -33,9 +33,12 @@ LIBELF_OBJS += libelf-dominfo.o
OBJS-y += $(LIBELF_OBJS)
ifeq ($(CONFIG_X86),y) # Add libx86 to the build
-vpath %.c ../../../xen/lib/x86
+vpath %.c $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy
-OBJS-y += cpuid.o msr.o policy.o
+lib-y :=
+include $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy/Makefile.common
+
+OBJS-y += $(lib-y)
endif
# new domain builder
diff --git a/tools/tests/cpu-policy/Makefile b/tools/tests/cpu-policy/Makefile
index 24f87e2eca2a..d8e4d222f4e4 100644
--- a/tools/tests/cpu-policy/Makefile
+++ b/tools/tests/cpu-policy/Makefile
@@ -42,11 +42,14 @@ CFLAGS += $(APPEND_CFLAGS)
LDFLAGS += $(APPEND_LDFLAGS)
-vpath %.c ../../../xen/lib/x86
+vpath %.c $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy
+
+lib-y :=
+include $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy/Makefile.common
%.o: Makefile
-test-cpu-policy: test-cpu-policy.o msr.o cpuid.o policy.o
+test-cpu-policy: test-cpu-policy.o $(lib-y)
$(CC) $^ -o $@ $(LDFLAGS)
-include $(DEPS_INCLUDE)
diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile
index 376cfe244d1c..e18725d0c303 100644
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -17,7 +17,7 @@ vpath x86_emulate/%.h $(XEN_ROOT)/xen/arch/x86
HOSTCFLAGS += -iquote $(XEN_ROOT)/xen/arch/x86
# Add libx86 to the build
-vpath %.c $(XEN_ROOT)/xen/lib/x86
+vpath %.c $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy
CFLAGS += $(CFLAGS_xeninclude)
diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk
index 0203138a819a..be6c76d2934b 100644
--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -4,6 +4,7 @@
export XEN_IMG_OFFSET := 0x200000
ARCH_LIBS-y += arch/x86/lib/lib.a
+ALL_LIBS-y += arch/x86/lib/cpu-policy/lib.a
CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
diff --git a/xen/arch/x86/lib/Makefile b/xen/arch/x86/lib/Makefile
index b9a65c662a56..fe9a27187992 100644
--- a/xen/arch/x86/lib/Makefile
+++ b/xen/arch/x86/lib/Makefile
@@ -6,3 +6,5 @@ lib-y += generic-hweightl.o
lib-y += memcpy.o
lib-y += memset.o
lib-y += scrub-page.o
+
+obj-y += cpu-policy/
diff --git a/xen/arch/x86/lib/cpu-policy/Makefile b/xen/arch/x86/lib/cpu-policy/Makefile
new file mode 100644
index 000000000000..b12cf7836d4c
--- /dev/null
+++ b/xen/arch/x86/lib/cpu-policy/Makefile
@@ -0,0 +1 @@
+include $(srcdir)/Makefile.common
diff --git a/xen/arch/x86/lib/cpu-policy/Makefile.common b/xen/arch/x86/lib/cpu-policy/Makefile.common
new file mode 100644
index 000000000000..35475af78048
--- /dev/null
+++ b/xen/arch/x86/lib/cpu-policy/Makefile.common
@@ -0,0 +1,3 @@
+lib-y += cpuid.o
+lib-y += msr.o
+lib-y += policy.o
diff --git a/xen/lib/x86/cpuid.c b/xen/arch/x86/lib/cpu-policy/cpuid.c
similarity index 100%
rename from xen/lib/x86/cpuid.c
rename to xen/arch/x86/lib/cpu-policy/cpuid.c
diff --git a/xen/lib/x86/msr.c b/xen/arch/x86/lib/cpu-policy/msr.c
similarity index 100%
rename from xen/lib/x86/msr.c
rename to xen/arch/x86/lib/cpu-policy/msr.c
diff --git a/xen/lib/x86/policy.c b/xen/arch/x86/lib/cpu-policy/policy.c
similarity index 100%
rename from xen/lib/x86/policy.c
rename to xen/arch/x86/lib/cpu-policy/policy.c
diff --git a/xen/lib/x86/private.h b/xen/arch/x86/lib/cpu-policy/private.h
similarity index 100%
rename from xen/lib/x86/private.h
rename to xen/arch/x86/lib/cpu-policy/private.h
diff --git a/xen/lib/Makefile b/xen/lib/Makefile
index efca830d924c..850efeb4c570 100644
--- a/xen/lib/Makefile
+++ b/xen/lib/Makefile
@@ -1,5 +1,3 @@
-obj-$(CONFIG_X86) += x86/
-
lib-y += bsearch.o
lib-y += ctors.o
lib-y += ctype.o
diff --git a/xen/lib/x86/Makefile b/xen/lib/x86/Makefile
deleted file mode 100644
index 780ea05db158..000000000000
--- a/xen/lib/x86/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-obj-y += cpuid.o
-obj-y += msr.o
-obj-y += policy.oOn 07/01/2026 2:17 pm, Jan Beulich wrote: > diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk > index 0203138a819a..be6c76d2934b 100644 > --- a/xen/arch/x86/arch.mk > +++ b/xen/arch/x86/arch.mk > @@ -4,6 +4,7 @@ > export XEN_IMG_OFFSET := 0x200000 > > ARCH_LIBS-y += arch/x86/lib/lib.a > +ALL_LIBS-y += arch/x86/lib/cpu-policy/lib.a This wants to extend ARCH_LIBS-y surely? Is this a rebasing oversight? ~Andrew
On 02.02.2026 16:47, Andrew Cooper wrote: > On 07/01/2026 2:17 pm, Jan Beulich wrote: >> diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk >> index 0203138a819a..be6c76d2934b 100644 >> --- a/xen/arch/x86/arch.mk >> +++ b/xen/arch/x86/arch.mk >> @@ -4,6 +4,7 @@ >> export XEN_IMG_OFFSET := 0x200000 >> >> ARCH_LIBS-y += arch/x86/lib/lib.a >> +ALL_LIBS-y += arch/x86/lib/cpu-policy/lib.a > > This wants to extend ARCH_LIBS-y surely? Is this a rebasing oversight? No, this was deliberate. The functions here are different from those in arch/x86/lib/lib.a. We don't need to fear collision with "common code" ones. Hence I preferred to use the more "normal" placement into what's passed to the linker. Jan
On 02/02/2026 4:26 pm, Jan Beulich wrote: > On 02.02.2026 16:47, Andrew Cooper wrote: >> On 07/01/2026 2:17 pm, Jan Beulich wrote: >>> diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk >>> index 0203138a819a..be6c76d2934b 100644 >>> --- a/xen/arch/x86/arch.mk >>> +++ b/xen/arch/x86/arch.mk >>> @@ -4,6 +4,7 @@ >>> export XEN_IMG_OFFSET := 0x200000 >>> >>> ARCH_LIBS-y += arch/x86/lib/lib.a >>> +ALL_LIBS-y += arch/x86/lib/cpu-policy/lib.a >> This wants to extend ARCH_LIBS-y surely? Is this a rebasing oversight? > No, this was deliberate. The functions here are different from those in > arch/x86/lib/lib.a. We don't need to fear collision with "common code" > ones. Hence I preferred to use the more "normal" placement into what's > passed to the linker. I agree that we don't have the explicit ordering requirement that we have with arch/x86/lib/lib.a. But, it still reads as bogus to be putting arch/x86/lib/cpu-policy/lib.a in the non-ARCH list. What difference is there having this a little earlier in the linker arguments? Nothing AFAICT. ~Andrew
On 23.02.2026 20:00, Andrew Cooper wrote: > On 02/02/2026 4:26 pm, Jan Beulich wrote: >> On 02.02.2026 16:47, Andrew Cooper wrote: >>> On 07/01/2026 2:17 pm, Jan Beulich wrote: >>>> diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk >>>> index 0203138a819a..be6c76d2934b 100644 >>>> --- a/xen/arch/x86/arch.mk >>>> +++ b/xen/arch/x86/arch.mk >>>> @@ -4,6 +4,7 @@ >>>> export XEN_IMG_OFFSET := 0x200000 >>>> >>>> ARCH_LIBS-y += arch/x86/lib/lib.a >>>> +ALL_LIBS-y += arch/x86/lib/cpu-policy/lib.a >>> This wants to extend ARCH_LIBS-y surely? Is this a rebasing oversight? >> No, this was deliberate. The functions here are different from those in >> arch/x86/lib/lib.a. We don't need to fear collision with "common code" >> ones. Hence I preferred to use the more "normal" placement into what's >> passed to the linker. > > I agree that we don't have the explicit ordering requirement that we > have with arch/x86/lib/lib.a. > > But, it still reads as bogus to be putting arch/x86/lib/cpu-policy/lib.a > in the non-ARCH list. > > What difference is there having this a little earlier in the linker > arguments? Nothing AFAICT. Indeed. The sole reason why I'd prefer things as presented is that putting stuff in ARCH_LIBS should imo be the special case (i.e. requiring a special reason), while putting things in ALL_LIBS should be the default. Jan
On Tue, Feb 24, 2026 at 07:54:29AM +0100, Jan Beulich wrote: > On 23.02.2026 20:00, Andrew Cooper wrote: > > On 02/02/2026 4:26 pm, Jan Beulich wrote: > >> On 02.02.2026 16:47, Andrew Cooper wrote: > >>> On 07/01/2026 2:17 pm, Jan Beulich wrote: > >>>> diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk > >>>> index 0203138a819a..be6c76d2934b 100644 > >>>> --- a/xen/arch/x86/arch.mk > >>>> +++ b/xen/arch/x86/arch.mk > >>>> @@ -4,6 +4,7 @@ > >>>> export XEN_IMG_OFFSET := 0x200000 > >>>> > >>>> ARCH_LIBS-y += arch/x86/lib/lib.a > >>>> +ALL_LIBS-y += arch/x86/lib/cpu-policy/lib.a > >>> This wants to extend ARCH_LIBS-y surely? Is this a rebasing oversight? > >> No, this was deliberate. The functions here are different from those in > >> arch/x86/lib/lib.a. We don't need to fear collision with "common code" > >> ones. Hence I preferred to use the more "normal" placement into what's > >> passed to the linker. > > > > I agree that we don't have the explicit ordering requirement that we > > have with arch/x86/lib/lib.a. > > > > But, it still reads as bogus to be putting arch/x86/lib/cpu-policy/lib.a > > in the non-ARCH list. > > > > What difference is there having this a little earlier in the linker > > arguments? Nothing AFAICT. > > Indeed. The sole reason why I'd prefer things as presented is that putting > stuff in ARCH_LIBS should imo be the special case (i.e. requiring a special > reason), while putting things in ALL_LIBS should be the default. I agree with Andrew that it feels weird that arch/x86/lib/lib.a is placed in ARCH_LIBS-y and arch/x86/lib/cpu-policy/lib.a is placed in ALL_LIBS-y. If we want to do it that way it needs a comment explaining why they are placed in different list, otherwise it seems like a typo on first sight, and it's likely to confuse people in the future. Thanks, Roger.
On 24.02.2026 09:53, Roger Pau Monné wrote: > On Tue, Feb 24, 2026 at 07:54:29AM +0100, Jan Beulich wrote: >> On 23.02.2026 20:00, Andrew Cooper wrote: >>> On 02/02/2026 4:26 pm, Jan Beulich wrote: >>>> On 02.02.2026 16:47, Andrew Cooper wrote: >>>>> On 07/01/2026 2:17 pm, Jan Beulich wrote: >>>>>> diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk >>>>>> index 0203138a819a..be6c76d2934b 100644 >>>>>> --- a/xen/arch/x86/arch.mk >>>>>> +++ b/xen/arch/x86/arch.mk >>>>>> @@ -4,6 +4,7 @@ >>>>>> export XEN_IMG_OFFSET := 0x200000 >>>>>> >>>>>> ARCH_LIBS-y += arch/x86/lib/lib.a >>>>>> +ALL_LIBS-y += arch/x86/lib/cpu-policy/lib.a >>>>> This wants to extend ARCH_LIBS-y surely? Is this a rebasing oversight? >>>> No, this was deliberate. The functions here are different from those in >>>> arch/x86/lib/lib.a. We don't need to fear collision with "common code" >>>> ones. Hence I preferred to use the more "normal" placement into what's >>>> passed to the linker. >>> >>> I agree that we don't have the explicit ordering requirement that we >>> have with arch/x86/lib/lib.a. >>> >>> But, it still reads as bogus to be putting arch/x86/lib/cpu-policy/lib.a >>> in the non-ARCH list. >>> >>> What difference is there having this a little earlier in the linker >>> arguments? Nothing AFAICT. >> >> Indeed. The sole reason why I'd prefer things as presented is that putting >> stuff in ARCH_LIBS should imo be the special case (i.e. requiring a special >> reason), while putting things in ALL_LIBS should be the default. > > I agree with Andrew that it feels weird that arch/x86/lib/lib.a is > placed in ARCH_LIBS-y and arch/x86/lib/cpu-policy/lib.a is placed in > ALL_LIBS-y. If we want to do it that way it needs a comment > explaining why they are placed in different list, otherwise it seems > like a typo on first sight, and it's likely to confuse people in the > future. Well, I'll (reluctantly) change then. Jan
On 24/02/2026 8:58 am, Jan Beulich wrote: > On 24.02.2026 09:53, Roger Pau Monné wrote: >> On Tue, Feb 24, 2026 at 07:54:29AM +0100, Jan Beulich wrote: >>> On 23.02.2026 20:00, Andrew Cooper wrote: >>>> On 02/02/2026 4:26 pm, Jan Beulich wrote: >>>>> On 02.02.2026 16:47, Andrew Cooper wrote: >>>>>> On 07/01/2026 2:17 pm, Jan Beulich wrote: >>>>>>> diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk >>>>>>> index 0203138a819a..be6c76d2934b 100644 >>>>>>> --- a/xen/arch/x86/arch.mk >>>>>>> +++ b/xen/arch/x86/arch.mk >>>>>>> @@ -4,6 +4,7 @@ >>>>>>> export XEN_IMG_OFFSET := 0x200000 >>>>>>> >>>>>>> ARCH_LIBS-y += arch/x86/lib/lib.a >>>>>>> +ALL_LIBS-y += arch/x86/lib/cpu-policy/lib.a >>>>>> This wants to extend ARCH_LIBS-y surely? Is this a rebasing oversight? >>>>> No, this was deliberate. The functions here are different from those in >>>>> arch/x86/lib/lib.a. We don't need to fear collision with "common code" >>>>> ones. Hence I preferred to use the more "normal" placement into what's >>>>> passed to the linker. >>>> I agree that we don't have the explicit ordering requirement that we >>>> have with arch/x86/lib/lib.a. >>>> >>>> But, it still reads as bogus to be putting arch/x86/lib/cpu-policy/lib.a >>>> in the non-ARCH list. >>>> >>>> What difference is there having this a little earlier in the linker >>>> arguments? Nothing AFAICT. >>> Indeed. The sole reason why I'd prefer things as presented is that putting >>> stuff in ARCH_LIBS should imo be the special case (i.e. requiring a special >>> reason), while putting things in ALL_LIBS should be the default. >> I agree with Andrew that it feels weird that arch/x86/lib/lib.a is >> placed in ARCH_LIBS-y and arch/x86/lib/cpu-policy/lib.a is placed in >> ALL_LIBS-y. If we want to do it that way it needs a comment >> explaining why they are placed in different list, otherwise it seems >> like a typo on first sight, and it's likely to confuse people in the >> future. > Well, I'll (reluctantly) change then. Thanks. With that done, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
© 2016 - 2026 Red Hat, Inc.