[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yv268Z0i+rq7r/oR@debian.me>
Date: Thu, 18 Aug 2022 11:07:13 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Kai Huang <kai.huang@...el.com>
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
kvm@...r.kernel.org, seanjc@...gle.com, pbonzini@...hat.com,
dave.hansen@...el.com, len.brown@...el.com, tony.luck@...el.com,
rafael.j.wysocki@...el.com, reinette.chatre@...el.com,
dan.j.williams@...el.com, peterz@...radead.org, ak@...ux.intel.com,
kirill.shutemov@...ux.intel.com,
sathyanarayanan.kuppuswamy@...ux.intel.com,
isaku.yamahata@...el.com
Subject: Re: [PATCH v5 22/22] Documentation/x86: Add documentation for TDX
host support
On Wed, Jun 22, 2022 at 11:17:50PM +1200, Kai Huang wrote:
> +Kernel detects TDX and the TDX private KeyIDs during kernel boot. User
> +can see below dmesg if TDX is enabled by BIOS:
> +
> +| [..] tdx: SEAMRR enabled.
> +| [..] tdx: TDX private KeyID range: [16, 64).
> +| [..] tdx: TDX enabled by BIOS.
> +
<snipped>
> +Initializing the TDX module consumes roughly ~1/256th system RAM size to
> +use it as 'metadata' for the TDX memory. It also takes additional CPU
> +time to initialize those metadata along with the TDX module itself. Both
> +are not trivial. Current kernel doesn't choose to always initialize the
> +TDX module during kernel boot, but provides a function tdx_init() to
> +allow the caller to initialize TDX when it truly wants to use TDX:
> +
> + ret = tdx_init();
> + if (ret)
> + goto no_tdx;
> + // TDX is ready to use
> +
Hi,
The code block above produces Sphinx warnings:
Documentation/x86/tdx.rst:69: WARNING: Unexpected indentation.
Documentation/x86/tdx.rst:70: WARNING: Block quote ends without a blank line; unexpected unindent.
I have applied the fixup:
---- >8 ----
diff --git a/Documentation/x86/tdx.rst b/Documentation/x86/tdx.rst
index 6c6b09ca6ba407..4430912a2e4f05 100644
--- a/Documentation/x86/tdx.rst
+++ b/Documentation/x86/tdx.rst
@@ -62,7 +62,7 @@ use it as 'metadata' for the TDX memory. It also takes additional CPU
time to initialize those metadata along with the TDX module itself. Both
are not trivial. Current kernel doesn't choose to always initialize the
TDX module during kernel boot, but provides a function tdx_init() to
-allow the caller to initialize TDX when it truly wants to use TDX:
+allow the caller to initialize TDX when it truly wants to use TDX::
ret = tdx_init();
if (ret)
> +If the TDX module is not loaded, dmesg shows below:
> +
> +| [..] tdx: TDX module is not loaded.
> +
> +If the TDX module is initialized successfully, dmesg shows something
> +like below:
> +
> +| [..] tdx: TDX module: vendor_id 0x8086, major_version 1, minor_version 0, build_date 20211209, build_num 160
> +| [..] tdx: 65667 pages allocated for PAMT.
> +| [..] tdx: TDX module initialized.
> +
> +If the TDX module failed to initialize, dmesg shows below:
> +
> +| [..] tdx: Failed to initialize TDX module. Shut it down.
<snipped>
> +There are basically two memory hot-add cases that need to be prevented:
> +ACPI memory hot-add and driver managed memory hot-add. The kernel
> +rejectes the driver managed memory hot-add too when TDX is enabled by
> +BIOS. For instance, dmesg shows below error when using kmem driver to
> +add a legacy PMEM as system RAM:
> +
> +| [..] tdx: Unable to add memory [0x580000000, 0x600000000) on TDX enabled platform.
> +| [..] kmem dax0.0: mapping0: 0x580000000-0x5ffffffff memory add failed
> +
For dmesg ouput, use literal code block instead of line blocks, like:
---- >8 ----
diff --git a/Documentation/x86/tdx.rst b/Documentation/x86/tdx.rst
index 4430912a2e4f05..1eaeb7cd14d76f 100644
--- a/Documentation/x86/tdx.rst
+++ b/Documentation/x86/tdx.rst
@@ -41,11 +41,11 @@ TDX boot-time detection
-----------------------
Kernel detects TDX and the TDX private KeyIDs during kernel boot. User
-can see below dmesg if TDX is enabled by BIOS:
+can see below dmesg if TDX is enabled by BIOS::
-| [..] tdx: SEAMRR enabled.
-| [..] tdx: TDX private KeyID range: [16, 64).
-| [..] tdx: TDX enabled by BIOS.
+ [..] tdx: SEAMRR enabled.
+ [..] tdx: TDX private KeyID range: [16, 64).
+ [..] tdx: TDX enabled by BIOS.
TDX module detection and initialization
---------------------------------------
@@ -79,20 +79,20 @@ caller.
User can consult dmesg to see the presence of the TDX module, and whether
it has been initialized.
-If the TDX module is not loaded, dmesg shows below:
+If the TDX module is not loaded, dmesg shows below::
-| [..] tdx: TDX module is not loaded.
+ [..] tdx: TDX module is not loaded.
If the TDX module is initialized successfully, dmesg shows something
-like below:
+like below::
-| [..] tdx: TDX module: vendor_id 0x8086, major_version 1, minor_version 0, build_date 20211209, build_num 160
-| [..] tdx: 65667 pages allocated for PAMT.
-| [..] tdx: TDX module initialized.
+ [..] tdx: TDX module: vendor_id 0x8086, major_version 1, minor_version 0, build_date 20211209, build_num 160
+ [..] tdx: 65667 pages allocated for PAMT.
+ [..] tdx: TDX module initialized.
-If the TDX module failed to initialize, dmesg shows below:
+If the TDX module failed to initialize, dmesg shows below::
-| [..] tdx: Failed to initialize TDX module. Shut it down.
+ [..] tdx: Failed to initialize TDX module. Shut it down.
TDX Interaction to Other Kernel Components
------------------------------------------
@@ -143,10 +143,10 @@ There are basically two memory hot-add cases that need to be prevented:
ACPI memory hot-add and driver managed memory hot-add. The kernel
rejectes the driver managed memory hot-add too when TDX is enabled by
BIOS. For instance, dmesg shows below error when using kmem driver to
-add a legacy PMEM as system RAM:
+add a legacy PMEM as system RAM::
-| [..] tdx: Unable to add memory [0x580000000, 0x600000000) on TDX enabled platform.
-| [..] kmem dax0.0: mapping0: 0x580000000-0x5ffffffff memory add failed
+ [..] tdx: Unable to add memory [0x580000000, 0x600000000) on TDX enabled platform.
+ [..] kmem dax0.0: mapping0: 0x580000000-0x5ffffffff memory add failed
However, adding new memory to ZONE_DEVICE should not be prevented as
those pages are not managed by the page allocator. Therefore,
Thanks.
--
An old man doll... just what I always wanted! - Clara
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists