BM(Bare Metal) involves testing on physical machines without any hypervisor or virtualization software.
- AMX
- avx512vbmi
- cet(Control flow Enhancement Technology)
- CMPccXADD
- cstate
- DSA
- FRED (in progress)
- guest-test
- idxd (TODO)
- IFS(In Field Scan)
- ISST
- PMU
- pstate
- Intel_PT
- RAPL
- SDSI
- splitlock
- tdx-compliance
- tdx-guest
- tdx-osv-sanity (TODO)
- telemetry
- tpm
- Intel_TH(Trace Hub)
- thermal
- topology
- tpmi
- ufs
- UMIP(User-Mode Instruction Prevention)
- workload-xsave
- xsave
Usually, it needs various dependencies if you're trying to compile the whole project locally.
git clone https://github.com/intel/lkvs.git
cd lkvs/BM
make
Each sub-project should detail its particular way, if any. There are some known dependency issues.
-
Overall general dependence check Please check the "Run Tests" section -d functionality below for general dependency checks on hardware, etc. (like kernel support, BIOS setting, Glibc support...).
-
Intel PT Cases of Intel PT need a 3rd part library libipt.
export GIT_SSL_NO_VERIFY=true
git clone http://github.com/intel/libipt.git
cd libipt && cmake . && make install
- UMIP The UMIP test has 32-bit compatibility tests and requires 32-bit Glibc to be installed for compilation. However, 32-bit Glibc support is not mandatory on Linux OS.
dpkg --add-architecture i386
dpkg --print-foreign-architectures
apt-get update
apt-get install gcc-11 make libelf1 gcc-multilib g++-multilib
Do not support 32-bit architect on other distributions.
For Ubuntu and so on deb package related OS:
dpkg -i linux-xxx-image_TARGET_VERSION.deb
dpkg -i linux-xxx-headers_TARGET_VERSION.deb
dpkg -i linux-xxx-dev_TARGET_VERSION.deb
dpkg -i linux-xxx-tools_TARGET_VERSION.deb
Boot up with target kernel version.
cd cet/cet_driver
make
For CentOS and so on rpm package related OS: Install the devel and headers package for target kernel and boot up with target kernel.
rpm -ivh --force kernel-TARGET_VERSION.rpm
rpm -ivh --force kernel-devel-TARGET_VERSION.rpm
rpm -ivh --force kernel-headers-TARGET_VERSION.rpm
Boot up with target kernel version.
cd cet_driver
make
make docker_image
make docker_make
Note. If you're behind a proxy, please export the local env variable https_proxy
before executing make
export https_proxy=https://proxy-domain:port
** This is the recommended way **
cd lkvs/BM/<test>
make
There're two ways to run the tests.
Normally, there're one or more executable binaries or scirpts in a sub-project, once it is compiled successfully. The easiest way is to run them directly.
runtests is a straightforward test runner that can execute a single or a set of test cases and redirect the log.
There are 2 ways to pass test to runtests, add point 3 and 4 for general dependence check:
-c
: Pass test cmdline.-f <component/tests*>
: thetests*
file under each component folder records the detailed test cmd lines.-d <component/tests*>
: thetests*
file under each component folder records the detailed test cmd lines.-d <tests-server|tests-client>
: tests-server or tests-client for all features dependence
Output of tests can be saved in a file using -o
option.
Examples:
$ ./runtests -f <cmdfile>
$ ./runtests -f <cmdfile> -o <logfile>
$ ./runtests -c <cmdline>
$ ./runtests -c <cmdline> -o <logfile>
$ ./runtests -d <cmdfile>
$ ./runtests -d <tests-server|tests-client>
The folders located in the root directory are referred to as "features." When naming a feature, please follow the following rule:
- Use a unified format for the feature name: - e.g. :cet, cstate, tdx-compliance, tdx-osv-sanity.
- Use the file name 'tests' for default
tests
if only one tests is needed. - Use the filename 'guest-tests' for guest tests.
tests|tests-server|tests-client file sample:
# @hw_dep: test dependence command @ the reason if the test command fails(optional)
# @other_dep:
# @other_warn:
For example:
# @hw_dep: cpuid_check 7 0 0 0 c 7
or
# @hw_dep: cpuid_check 7 0 0 0 c 7 @ CPU doesn't support CET SHSTK CPUID.(EAX=07H,ECX=01H):ECX[bit 7]
Failure of the @hw_dep and @other_dep test dependency commands will prevent this feature (folder) testing.
@other_warn the dependency check does not prevent testing of this feature, it just does some dependency checks and gives the reason why the feature partially fails due to some dependencies.
Use feature.guest_test_executor.sh as the entry point for guest tests.