The exception vector constants CP_VECTOR, HV_VECTOR, VC_VECTOR, and SX_VECTOR are used in ex_str(), but the header that defines them is not included. Other exception vectors are picked up through indirect includes, but these four are not, which leads to unresolved identifiers during selftest builds.
lib/x86/processor.c: In function ‘ex_str’: lib/x86/processor.c:52:17: error: ‘CP_VECTOR’ undeclared lib/x86/processor.c:53:17: error: ‘HV_VECTOR’ undeclared lib/x86/processor.c:54:17: error: ‘VC_VECTOR’ undeclared lib/x86/processor.c:55:17: error: ‘SX_VECTOR’ undeclared
These vector definitions live in:
tools/arch/x86/include/uapi/asm/kvm.h
Add the missing include the userspace API exception vector constants.
Signed-off-by: Ankit Khushwaha ankitkhushwaha.linux@gmail.com --- tools/testing/selftests/kvm/lib/x86/processor.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/kvm/lib/x86/processor.c b/tools/testing/selftests/kvm/lib/x86/processor.c index b418502c5ecc..fb589f07f2a4 100644 --- a/tools/testing/selftests/kvm/lib/x86/processor.c +++ b/tools/testing/selftests/kvm/lib/x86/processor.c @@ -4,6 +4,7 @@ */
#include "linux/bitmap.h" +#include "uapi/asm/kvm.h" #include "test_util.h" #include "kvm_util.h" #include "pmu.h" -- 2.51.1
On Sat, Nov 15, 2025, Ankit Khushwaha wrote:
The exception vector constants CP_VECTOR, HV_VECTOR, VC_VECTOR, and SX_VECTOR are used in ex_str(), but the header that defines them is not included. Other exception vectors are picked up through indirect includes, but these four are not, which leads to unresolved
That means your build is picking up stale kernel headers (likely the ones installed system-wide). The "#include <asm/kvm.h>" in kvm_util.h is what pulls in the kernel uAPI headers.
Selftests uapi headers are a bit of a mess. In the past, selftests would automatically do "make headers_install" as part of the build, but commit 3bb267a36185 ("selftests: drop khdr make target") yanked that out because there are scenarios where it broke the build.
So the "right" way to build selftest is to first do "make headers_install", and then build selftests.
Note, if you build KVM selftests directly, tools/testing/selftests/lib.mk will define the includes to be relative to the source directory, i.e. expects the headers to be installed in the source.
ifeq ($(KHDR_INCLUDES),) KHDR_INCLUDES := -isystem $(top_srcdir)/usr/include endif
You can explicitly set KHDR_INCLUDES when building if you install headers somewhere else. E.g. my build invocation looks something like this, where "$output" is an out-of-tree directory.
KHDR_INCLUDES="-isystem $output/usr/include" EXTRA_CFLAGS="-static -Werror -gdwarf-4" make \ INSTALL_HDR_PATH="$output/usr" OUTPUT=$output
On Mon, Nov 17, 2025 at 07:06:57AM -0800, Sean Christopherson wrote:
That means your build is picking up stale kernel headers (likely the ones installed system-wide). The "#include <asm/kvm.h>" in kvm_util.h is what pulls in the kernel uAPI headers.
Selftests uapi headers are a bit of a mess. In the past, selftests would automatically do "make headers_install" as part of the build, but commit 3bb267a36185 ("selftests: drop khdr make target") yanked that out because there are scenarios where it broke the build.
So the "right" way to build selftest is to first do "make headers_install", and then build selftests.
Note, if you build KVM selftests directly, tools/testing/selftests/lib.mk will define the includes to be relative to the source directory, i.e. expects the headers to be installed in the source.
ifeq ($(KHDR_INCLUDES),) KHDR_INCLUDES := -isystem $(top_srcdir)/usr/include endif
You can explicitly set KHDR_INCLUDES when building if you install headers somewhere else. E.g. my build invocation looks something like this, where "$output" is an out-of-tree directory.
KHDR_INCLUDES="-isystem $output/usr/include" EXTRA_CFLAGS="-static -Werror -gdwarf-4" make \ INSTALL_HDR_PATH="$output/usr" OUTPUT=$output
Hi Sean, Thanks for pointing it out, i am not aware of these details. Will take care of this now onwards
Thank you -- Ankit
linux-kselftest-mirror@lists.linaro.org