Updated the architecture.rst page with the following changes:
-Add missing article _the_ across the document.
-Reword content across for style and standard.
-Update all occurrences of Command Line to
Command-line across the document.
-Correct grammatical issues, for example, added _it_
wherever missing.
-Update all occurrences of “via" to either
use “through” or “using”.
-Update the text preceding the external links and pushed
the full link to a new line for better readability.
-Reword content under the config command to make it
more clear and concise.
Signed-off-by: Sadiya Kazi <sadiyakazi(a)google.com>
---
Thank you David and Bagas for reviewing the doc. I have added the feedback.
Changes since V1:
https://lore.kernel.org/linux-kselftest/20221010171353.1106166-1-sadiyakazi…
- Corrected the typo in the commit message.
- Followed the style for links as suggested by Bagas throughout the document.
- Updated the links for latest versions whereever applicable
(Note: Links having no changes between 5.15 and 6.0 have been retained).
- Updated the KTAP spec link to point to Documentation/dev-tools/ktap.rst.
- Reworded content as per David and Bagas's feedback.
---
.../dev-tools/kunit/architecture.rst | 114 +++++++++---------
1 file changed, 57 insertions(+), 57 deletions(-)
diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst
index 8efe792bdcb9..b8ee0fa8afc3 100644
--- a/Documentation/dev-tools/kunit/architecture.rst
+++ b/Documentation/dev-tools/kunit/architecture.rst
@@ -4,16 +4,17 @@
KUnit Architecture
==================
-The KUnit architecture can be divided into two parts:
+The KUnit architecture is divided into two parts:
- `In-Kernel Testing Framework`_
-- `kunit_tool (Command Line Test Harness)`_
+- `kunit_tool (Command-line Test Harness)`_
In-Kernel Testing Framework
===========================
The kernel testing library supports KUnit tests written in C using
-KUnit. KUnit tests are kernel code. KUnit does several things:
+KUnit. These KUnit tests are kernel code. KUnit performs the following
+tasks:
- Organizes tests
- Reports test results
@@ -22,19 +23,17 @@ KUnit. KUnit tests are kernel code. KUnit does several things:
Test Cases
----------
-The fundamental unit in KUnit is the test case. The KUnit test cases are
-grouped into KUnit suites. A KUnit test case is a function with type
-signature ``void (*)(struct kunit *test)``.
-These test case functions are wrapped in a struct called
-struct kunit_case.
+The test case is the fundamental unit in KUnit. KUnit test cases are organised
+into suites. A KUnit test case is a function with type signature
+``void (*)(struct kunit *test)``. These test case functions are wrapped in a
+struct called struct kunit_case.
.. note:
``generate_params`` is optional for non-parameterized tests.
-Each KUnit test case gets a ``struct kunit`` context
-object passed to it that tracks a running test. The KUnit assertion
-macros and other KUnit utilities use the ``struct kunit`` context
-object. As an exception, there are two fields:
+Each KUnit test case receives a ``struct kunit`` context object that tracks a
+running test. The KUnit assertion macros and other KUnit utilities use the
+``struct kunit`` context object. As an exception, there are two fields:
- ``->priv``: The setup functions can use it to store arbitrary test
user data.
@@ -77,12 +76,12 @@ Executor
The KUnit executor can list and run built-in KUnit tests on boot.
The Test suites are stored in a linker section
-called ``.kunit_test_suites``. For code, see:
-https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/asm-generic/vmlinux.lds.h?h=v5.15#n945.
+called ``.kunit_test_suites``. For the full code, see
+`include/asm-generic/vmlinux.lds.h <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/inc…>`_ .
The linker section consists of an array of pointers to
``struct kunit_suite``, and is populated by the ``kunit_test_suites()``
-macro. To run all tests compiled into the kernel, the KUnit executor
-iterates over the linker section array.
+macro. The KUnit executor iterates over the linker section array in order to
+run all the tests that are compiled into the kernel.
.. kernel-figure:: kunit_suitememorydiagram.svg
:alt: KUnit Suite Memory
@@ -90,17 +89,16 @@ iterates over the linker section array.
KUnit Suite Memory Diagram
On the kernel boot, the KUnit executor uses the start and end addresses
-of this section to iterate over and run all tests. For code, see:
-https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kunit/executor.c
-
+of this section to iterate over and run all tests. For the full code, see
+`executor.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib…>`_.
When built as a module, the ``kunit_test_suites()`` macro defines a
``module_init()`` function, which runs all the tests in the compilation
unit instead of utilizing the executor.
In KUnit tests, some error classes do not affect other tests
or parts of the kernel, each KUnit case executes in a separate thread
-context. For code, see:
-https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kunit/try-catch.c?h=v5.15#n58
+context. For the full code, see
+`try-catch.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib…>`_.
Assertion Macros
----------------
@@ -111,37 +109,36 @@ All expectations/assertions are formatted as:
- ``{EXPECT|ASSERT}`` determines whether the check is an assertion or an
expectation.
+ In the event of a failure, the testing flow differs as follows:
- - For an expectation, if the check fails, marks the test as failed
- and logs the failure.
+ - For expectations, the test is marked as failed and the failure is logged.
- - An assertion, on failure, causes the test case to terminate
- immediately.
+ - Failing assertions, on the other hand, result in the test case being
+ terminated immediately.
- - Assertions call function:
+ - Assertions call the function:
``void __noreturn kunit_abort(struct kunit *)``.
- - ``kunit_abort`` calls function:
+ - ``kunit_abort`` calls the function:
``void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch)``.
- - ``kunit_try_catch_throw`` calls function:
+ - ``kunit_try_catch_throw`` calls the function:
``void kthread_complete_and_exit(struct completion *, long) __noreturn;``
and terminates the special thread context.
- ``<op>`` denotes a check with options: ``TRUE`` (supplied property
- has the boolean value “true”), ``EQ`` (two supplied properties are
+ has the boolean value "true"), ``EQ`` (two supplied properties are
equal), ``NOT_ERR_OR_NULL`` (supplied pointer is not null and does not
- contain an “err” value).
+ contain an "err" value).
- ``[_MSG]`` prints a custom message on failure.
Test Result Reporting
---------------------
-KUnit prints test results in KTAP format. KTAP is based on TAP14, see:
-https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-specification.md.
-KTAP (yet to be standardized format) works with KUnit and Kselftest.
-The KUnit executor prints KTAP results to dmesg, and debugfs
-(if configured).
+KUnit prints the test results in KTAP format. KTAP is based on TAP14, see
+Documentation/dev-tools/ktap.rst.
+KTAP works with KUnit and Kselftest. The KUnit executor prints KTAP results to
+dmesg, and debugfs (if configured).
Parameterized Tests
-------------------
@@ -150,33 +147,33 @@ Each KUnit parameterized test is associated with a collection of
parameters. The test is invoked multiple times, once for each parameter
value and the parameter is stored in the ``param_value`` field.
The test case includes a KUNIT_CASE_PARAM() macro that accepts a
-generator function.
-The generator function is passed the previous parameter and returns the next
-parameter. It also provides a macro to generate common-case generators based on
-arrays.
+generator function. The generator function is passed the previous parameter
+and returns the next parameter. It also includes a macro for generating
+array-based common-case generators.
-kunit_tool (Command Line Test Harness)
+kunit_tool (Command-line Test Harness)
======================================
-kunit_tool is a Python script ``(tools/testing/kunit/kunit.py)``
-that can be used to configure, build, exec, parse and run (runs other
-commands in order) test results. You can either run KUnit tests using
-kunit_tool or can include KUnit in kernel and parse manually.
+``kunit_tool`` is a Python script, found in ``tools/testing/kunit/kunit.py``. It
+is used to configure, build, execute, parse test results and run all of the
+previous commands in correct order (i.e., configure, build, execute and parse).
+You have two options for running KUnit tests: either use KUnit
+directly through the kernel and parse manually, or use the ``kunit_tool``.
- ``configure`` command generates the kernel ``.config`` from a
``.kunitconfig`` file (and any architecture-specific options).
- For some architectures, additional config options are specified in the
- ``qemu_config`` Python script
- (For example: ``tools/testing/kunit/qemu_configs/powerpc.py``).
+ The Python scripts available in ``qemu_configs`` folder
+ (for example, ``tools/testing/kunit/qemu configs/powerpc.py``) contains
+ additional configuration options for specific architectures.
It parses both the existing ``.config`` and the ``.kunitconfig`` files
- and ensures that ``.config`` is a superset of ``.kunitconfig``.
- If this is not the case, it will combine the two and run
- ``make olddefconfig`` to regenerate the ``.config`` file. It then
- verifies that ``.config`` is now a superset. This checks if all
- Kconfig dependencies are correctly specified in ``.kunitconfig``.
- ``kunit_config.py`` includes the parsing Kconfigs code. The code which
- runs ``make olddefconfig`` is a part of ``kunit_kernel.py``. You can
- invoke this command via: ``./tools/testing/kunit/kunit.py config`` and
+ to ensure that ``.config`` is a superset of ``.kunitconfig``.
+ If not, it will combine the two and run ``make olddefconfig`` to regenerate
+ the ``.config`` file. It then checks to see if ``.config`` has become a superset.
+ This verifies that all the Kconfig dependencies are correctly specified in the file
+ ``.kunitconfig``. The ``kunit_config.py`` script contains the code for parsing
+ Kconfigs. The code which runs ``make olddefconfig`` is part of the
+ ``kunit_kernel.py`` script. You can invoke this command through:
+ ``./tools/testing/kunit/kunit.py config`` and
generate a ``.config`` file.
- ``build`` runs ``make`` on the kernel tree with required options
(depends on the architecture and some options, for example: build_dir)
@@ -184,8 +181,8 @@ kunit_tool or can include KUnit in kernel and parse manually.
To build a KUnit kernel from the current ``.config``, you can use the
``build`` argument: ``./tools/testing/kunit/kunit.py build``.
- ``exec`` command executes kernel results either directly (using
- User-mode Linux configuration), or via an emulator such
- as QEMU. It reads results from the log via standard
+ User-mode Linux configuration), or through an emulator such
+ as QEMU. It reads results from the log using standard
output (stdout), and passes them to ``parse`` to be parsed.
If you already have built a kernel with built-in KUnit tests,
you can run the kernel and display the test results with the ``exec``
@@ -193,3 +190,6 @@ kunit_tool or can include KUnit in kernel and parse manually.
- ``parse`` extracts the KTAP output from a kernel log, parses
the test results, and prints a summary. For failed tests, any
diagnostic output will be included.
+
+For more information on kunit_tool, see
+Documentation/dev-tools/kunit/run_wrapper.rst.
--
2.38.0.rc1.362.ged0d419d3c-goog
Hi All,
Intel's Trust Domain Extensions (TDX) protect guest VMs from malicious
hosts and some physical attacks. VM guest with TDX support is called
as a TDX Guest.
In TDX guest, attestation process is used to verify the TDX guest
trustworthiness to other entities before provisioning secrets to the
guest. For example, a key server may request for attestation before
releasing the encryption keys to mount the encrypted rootfs or
secondary drive.
This patch set adds attestation support for the TDX guest. Details
about the TDX attestation process and the steps involved are explained
in Documentation/x86/tdx.rst (added by patch 2/3).
Following are the details of the patch set:
Patch 1/3 -> Preparatory patch for adding attestation support.
Patch 2/3 -> Adds user interface driver to support attestation.
Patch 3/3 -> Adds selftest support for TDREPORT feature.
Commit log history is maintained in the individual patches.
Kuppuswamy Sathyanarayanan (3):
x86/tdx: Make __tdx_module_call() usable in driver module
virt: Add TDX guest driver
selftests: tdx: Test TDX attestation GetReport support
Documentation/virt/coco/tdx-guest.rst | 42 +++++
Documentation/virt/index.rst | 1 +
Documentation/x86/tdx.rst | 43 +++++
arch/x86/coco/tdx/tdcall.S | 2 +
arch/x86/coco/tdx/tdx.c | 5 -
arch/x86/include/asm/tdx.h | 6 +
drivers/virt/Kconfig | 2 +
drivers/virt/Makefile | 1 +
drivers/virt/coco/tdx-guest/Kconfig | 10 ++
drivers/virt/coco/tdx-guest/Makefile | 2 +
drivers/virt/coco/tdx-guest/tdx-guest.c | 131 ++++++++++++++
include/uapi/linux/tdx-guest.h | 53 ++++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/tdx/Makefile | 7 +
tools/testing/selftests/tdx/config | 1 +
tools/testing/selftests/tdx/tdx_guest_test.c | 175 +++++++++++++++++++
16 files changed, 477 insertions(+), 5 deletions(-)
create mode 100644 Documentation/virt/coco/tdx-guest.rst
create mode 100644 drivers/virt/coco/tdx-guest/Kconfig
create mode 100644 drivers/virt/coco/tdx-guest/Makefile
create mode 100644 drivers/virt/coco/tdx-guest/tdx-guest.c
create mode 100644 include/uapi/linux/tdx-guest.h
create mode 100644 tools/testing/selftests/tdx/Makefile
create mode 100644 tools/testing/selftests/tdx/config
create mode 100644 tools/testing/selftests/tdx/tdx_guest_test.c
--
2.34.1
This series is posted in context of the discussion at:
https://lore.kernel.org/lkml/Ywa9T+jKUpaHLu%2Fl@google.com/
Changes in v2:
* Addressed comments from Andrew and David
* Common function with constructor attribute used to setup initial state
* Changes are split in more logical granules as per feedback
Major changes:
1) Move common startup logic to a single function in kvm_util.c
2) Introduce following APIs:
kvm_selftest_arch_init: to perform arch specific common startup.
kvm_arch_post_vm_elf_load: to update the guest memory state to convey
common information to guests.
3) For x86, capture cpu type at startup and pass on the cpu type to
guest after guest elf is loaded.
4) Execute hypercall instruction from within guest VMs according to the
cpu type. This will help prevent an extra kvm exit during hypercall
execution.
Vishal Annapurve (8):
KVM: selftests: move common startup logic to kvm_util.c
KVM: selftests: Add arch specific initialization
KVM: selftests: Add arch specific post vm load setup
KVM: selftests: x86: Precompute the result for is_{intel,amd}_cpu()
KVM: selftests: x86: delete svm_vmcall_test
KVM: selftests: x86: Execute cpu specific hypercall from nested guests
Kvm: selftests: x86: Execute cpu specific vmcall instruction
KVM: selftests: x86: xen: Execute cpu specific vmcall instruction
tools/testing/selftests/kvm/.gitignore | 1 -
.../selftests/kvm/aarch64/arch_timer.c | 3 -
.../selftests/kvm/aarch64/hypercalls.c | 2 -
.../testing/selftests/kvm/aarch64/vgic_irq.c | 3 -
.../selftests/kvm/include/kvm_util_base.h | 9 +++
.../selftests/kvm/include/x86_64/processor.h | 10 +++
.../selftests/kvm/include/x86_64/vmx.h | 9 ---
.../selftests/kvm/lib/aarch64/processor.c | 22 +++---
tools/testing/selftests/kvm/lib/elf.c | 2 +
tools/testing/selftests/kvm/lib/kvm_util.c | 8 ++
.../selftests/kvm/lib/riscv/processor.c | 8 ++
.../selftests/kvm/lib/s390x/processor.c | 8 ++
.../selftests/kvm/lib/x86_64/perf_test_util.c | 2 +-
.../selftests/kvm/lib/x86_64/processor.c | 38 +++++++++-
.../testing/selftests/kvm/memslot_perf_test.c | 3 -
tools/testing/selftests/kvm/rseq_test.c | 3 -
tools/testing/selftests/kvm/s390x/memop.c | 2 -
tools/testing/selftests/kvm/s390x/resets.c | 2 -
.../selftests/kvm/s390x/sync_regs_test.c | 3 -
.../selftests/kvm/set_memory_region_test.c | 3 -
.../kvm/x86_64/cr4_cpuid_sync_test.c | 3 -
.../kvm/x86_64/emulator_error_test.c | 3 -
.../selftests/kvm/x86_64/hyperv_cpuid.c | 3 -
.../selftests/kvm/x86_64/platform_info_test.c | 3 -
.../kvm/x86_64/pmu_event_filter_test.c | 3 -
.../selftests/kvm/x86_64/set_sregs_test.c | 3 -
tools/testing/selftests/kvm/x86_64/smm_test.c | 2 +-
.../testing/selftests/kvm/x86_64/state_test.c | 8 +-
.../kvm/x86_64/svm_nested_soft_inject_test.c | 3 -
.../selftests/kvm/x86_64/svm_vmcall_test.c | 74 -------------------
.../selftests/kvm/x86_64/sync_regs_test.c | 3 -
.../selftests/kvm/x86_64/userspace_io_test.c | 3 -
.../kvm/x86_64/userspace_msr_exit_test.c | 3 -
.../kvm/x86_64/vmx_apic_access_test.c | 2 +-
.../selftests/kvm/x86_64/vmx_dirty_log_test.c | 2 +-
.../kvm/x86_64/vmx_nested_tsc_scaling_test.c | 2 +-
.../kvm/x86_64/vmx_preemption_timer_test.c | 2 +-
.../kvm/x86_64/vmx_tsc_adjust_test.c | 2 +-
.../selftests/kvm/x86_64/xen_shinfo_test.c | 64 ++++++----------
.../selftests/kvm/x86_64/xen_vmcall_test.c | 14 +++-
40 files changed, 138 insertions(+), 205 deletions(-)
delete mode 100644 tools/testing/selftests/kvm/x86_64/svm_vmcall_test.c
--
2.37.2.789.g6183377224-goog