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