* Re: [PATCH v3 17/26] x86/virt/tdx: Reset software states after TDX module shutdown
From: Tony Lindgren @ 2026-01-26 10:43 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-18-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:25AM -0800, Chao Gao wrote:
> The TDX module requires a one-time global initialization (TDH.SYS.INIT) and
> per-CPU initialization (TDH.SYS.LP.INIT) before use. These initializations
> are guarded by software flags to prevent repetition.
>
> After TDX module updates, the new TDX module requires the same global and
> per-CPU initializations, but the existing software flags prevent
> re-initialization.
>
> Reset all software flags guarding the initialization flows to allow the
> global and per-CPU initializations to be triggered again after updates.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 16/26] x86/virt/seamldr: Shut down the current TDX module
From: Tony Lindgren @ 2026-01-26 10:42 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-17-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:24AM -0800, Chao Gao wrote:
> TDX Module updates request shutting down the existing TDX module.
> During this shutdown, the module generates hand-off data, which captures
> the module's states essential for preserving running TDs. The new TDX
> Module can utilize this hand-off data to establish its states.
>
> Invoke the TDH_SYS_SHUTDOWN SEAMCALL on one CPU to perform the shutdown.
> This SEAMCALL requires a hand-off module version. Use the module's own
> hand-off version, as it is the highest version the module can produce and
> is more likely to be compatible with new modules as new modules likely have
> higher hand-off version.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 15/26] x86/virt/seamldr: Abort updates if errors occurred midway
From: Tony Lindgren @ 2026-01-26 10:31 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-16-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:23AM -0800, Chao Gao wrote:
> The TDX Module update process has multiple stages, each of which may
> encounter failures.
>
> The current state machine of updates proceeds to the next stage
> regardless of errors. But continuing updates when errors occur midway
> is pointless.
>
> If a CPU encounters an error, abort the update by setting a flag and
> exiting the execution loop. Note that this CPU doesn't acknowledge the
> current stage. This will keep all other CPUs in the current stage until
> they see the flag and exit the loop as well.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 14/26] x86/virt/seamldr: Introduce skeleton for TDX Module updates
From: Tony Lindgren @ 2026-01-26 10:28 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-15-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:22AM -0800, Chao Gao wrote:
> The P-SEAMLDR requires that no TDX Module SEAMCALLs are invoked during a
> runtime TDX Module update.
>
> But currently, TDX Module SEAMCALLs are invoked in various contexts and in
> parallel across CPUs. Additionally, considering the need to force all vCPUs
> out of guest mode, no single lock primitive, except for stop_machine(), can
> meet this requirement.
>
> Perform TDX Module updates within stop_machine() as it achieves the
> P-SEAMLDR requirements and is an existing well understood mechanism.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 13/26] x86/virt/seamldr: Allocate and populate a module update request
From: Tony Lindgren @ 2026-01-26 10:23 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-14-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:21AM -0800, Chao Gao wrote:
> A module update request is a struct used to describe information about
> the TDX module to install. It is part of the P-SEAMLDR <-> kernel ABI
> and is accepted by the SEAMLDR_INSTALL SEAMCALL.
>
> The request includes pointers to pages that contain the module binary, a
> pointer to a sigstruct file, and an update scenario.
>
> Define the request struct according to the P-SEAMLDR spec [1], and parse
> the bitstream from userspace to populate that struct for later module
> updates.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 12/26] x86/virt/seamldr: Verify availability of slots for TDX Module updates
From: Tony Lindgren @ 2026-01-26 10:17 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-13-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:20AM -0800, Chao Gao wrote:
> The CPU keeps track of TCB versions for each TDX Module that has been
> loaded. Since this tracking database has finite capacity, there's a maximum
> number of module updates that can be performed. After each successful
> update, the number reduces by one. Once it reaches zero, further updates
> will fail until next reboot.
>
> Before updating the TDX Module, ensure that the limit on TDX Module updates
> has not been exceeded to prevent update failures in a later phase where TDs
> have to be killed.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 11/26] x86/virt/seamldr: Block TDX Module updates if any CPU is offline
From: Tony Lindgren @ 2026-01-26 10:16 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-12-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:19AM -0800, Chao Gao wrote:
> P-SEAMLDR requires every CPU to call the SEAMLDR.INSTALL SEAMCALL during
> updates. So, every CPU should be online.
>
> Check if all CPUs are online and abort the update if any CPU is offline at
> the very beginning. Without this check, P-SEAMLDR will report failure at a
> later phase where the old TDX module is gone and TDs have to be killed.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 08/26] x86/virt/seamldr: Retrieve P-SEAMLDR information
From: Tony Lindgren @ 2026-01-26 10:15 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-9-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:16AM -0800, Chao Gao wrote:
> P-SEAMLDR returns its information e.g., version and supported features, in
> response to the SEAMLDR.INFO SEAMCALL.
>
> This information is useful for userspace. For example, the admin can decide
> which TDX module versions are compatible with the P-SEAMLDR according to
> the P-SEAMLDR version.
>
> Add and export seamldr_get_info() which retrieves P-SEAMLDR information by
> invoking SEAMLDR.INFO SEAMCALL in preparation for exposing P-SEAMLDR
> version and other necessary information to userspace.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 07/26] x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs
From: Tony Lindgren @ 2026-01-26 10:12 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-8-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:15AM -0800, Chao Gao wrote:
> --- a/drivers/virt/coco/tdx-host/Kconfig
> +++ b/drivers/virt/coco/tdx-host/Kconfig
> @@ -8,3 +8,13 @@ config TDX_HOST_SERVICES
>
> Say y or m if enabling support for confidential virtual machine
> support (CONFIG_INTEL_TDX_HOST). The module is called tdx_host.ko
> +
> +config INTEL_TDX_MODULE_UPDATE
> + bool "Intel TDX module runtime update"
> + depends on TDX_HOST_SERVICES
> + help
> + This enables the kernel to support TDX module runtime update. This
> + allows the admin to update the TDX module to another compatible
> + version without the need to terminate running TDX guests.
> +
> + If unsure, say N.
How about leave out the first "This" above:
Enable the kernel to support TDX module runtime update. This
allows the admin to update the TDX module to another compatible
version without the need to terminate running TDX guests.
Other than that:
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 06/26] x86/virt/tdx: Prepare to support P-SEAMLDR SEAMCALLs
From: Tony Lindgren @ 2026-01-26 10:05 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-7-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:14AM -0800, Chao Gao wrote:
> P-SEAMLDR is another component alongside the TDX module within the
> protected SEAM range. P-SEAMLDR can update the TDX module at runtime.
> Software can talk with P-SEAMLDR via SEAMCALLs with the bit 63 of RAX
> (leaf number) set to 1 (a.k.a P-SEAMLDR SEAMCALLs).
>
> P-SEAMLDR SEAMCALLs differ from SEAMCALLs of the TDX module in terms of
> error codes and the handling of the current VMCS.
>
> In preparation for adding support for P-SEAMLDR SEAMCALLs, do the two
> following changes to SEAMCALL low-level helpers:
>
> 1) Tweak sc_retry() to retry on "lack of entropy" errors reported by
> P-SEAMLDR because it uses a different error code.
>
> 2) Add seamldr_err() to log error messages on P-SEAMLDR SEAMCALL failures.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 03/26] x86/virt/tdx: Move low level SEAMCALL helpers out of <asm/tdx.h>
From: Tony Lindgren @ 2026-01-26 10:02 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-4-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:11AM -0800, Chao Gao wrote:
> From: Kai Huang <kai.huang@intel.com>
>
> TDX host core code implements three seamcall*() helpers to make SEAMCALL
> to the TDX module. Currently, they are implemented in <asm/tdx.h> and
> are exposed to other kernel code which includes <asm/tdx.h>.
>
> However, other than the TDX host core, seamcall*() are not expected to
> be used by other kernel code directly. For instance, for all SEAMCALLs
> that are used by KVM, the TDX host core exports a wrapper function for
> each of them.
>
> Move seamcall*() and related code out of <asm/tdx.h> and make them only
> visible to TDX host core.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 02/26] x86/virt/tdx: Use %# prefix for hex values in SEAMCALL error messages
From: Tony Lindgren @ 2026-01-26 10:02 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-3-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:10AM -0800, Chao Gao wrote:
> "%#" format specifier automatically adds the "0x" prefix and has one less
> character than "0x%".
>
> For conciseness, replace "0x%" with "%#" when printing hexadecimal values
> in SEAMCALL error messages.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 01/26] x86/virt/tdx: Print SEAMCALL leaf numbers in decimal
From: Tony Lindgren @ 2026-01-26 10:01 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Kirill A. Shutemov, Farrah Chen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-2-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:09AM -0800, Chao Gao wrote:
> Both TDX spec and kernel defines SEAMCALL leaf numbers as decimal. Printing
> them in hex makes no sense. Correct it.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 10/26] coco/tdx-host: Implement FW_UPLOAD sysfs ABI for TDX Module updates
From: Tony Lindgren @ 2026-01-26 10:00 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-11-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:18AM -0800, Chao Gao wrote:
> The firmware upload framework provides a standard mechanism for firmware
> updates by allowing device drivers to expose sysfs interfaces for
> user-initiated updates.
>
> Register with this framework to expose sysfs interfaces for TDX Module
> updates and implement operations to process data blobs supplied by
> userspace.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 09/26] coco/tdx-host: Expose P-SEAMLDR information via sysfs
From: Tony Lindgren @ 2026-01-26 9:56 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen
In-Reply-To: <20260123145645.90444-10-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:17AM -0800, Chao Gao wrote:
> TDX Module updates require userspace to select the appropriate module
> to load. Expose necessary information to facilitate this decision. Two
> values are needed:
>
> - P-SEAMLDR version: for compatibility checks between TDX Module and
> P-SEAMLDR
This is great to have:
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 05/26] coco/tdx-host: Expose TDX Module version
From: Tony Lindgren @ 2026-01-26 9:54 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma
In-Reply-To: <20260123145645.90444-6-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:13AM -0800, Chao Gao wrote:
> Expose the TDX Module version to userspace via sysfs to aid module
> selection. Since the TDX faux device will drive module updates, expose
> the version as its attribute.
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 04/26] coco/tdx-host: Introduce a "tdx_host" device
From: Tony Lindgren @ 2026-01-26 9:52 UTC (permalink / raw)
To: Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, seanjc, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Jonathan Cameron, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20260123145645.90444-5-chao.gao@intel.com>
On Fri, Jan 23, 2026 at 06:55:12AM -0800, Chao Gao wrote:
> --- /dev/null
> +++ b/drivers/virt/coco/tdx-host/tdx-host.c
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * TDX host user interface driver
> + *
> + * Copyright (C) 2025 Intel Corporation
> + */
Just a nit, the year has changed so could be updated.
Good to see the TDX host device get added:
Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v12 22/46] arm64: RMI: Create the realm descriptor
From: Steven Price @ 2026-01-26 9:50 UTC (permalink / raw)
To: Alper Gun
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Suzuki K Poulose, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Gavin Shan, Shanker Donthineni, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <CABpDEumQ=62nZ_xEN6oMHw=J+6ps=Gy=1vx8i=6Hz+BacO1Ymg@mail.gmail.com>
On 23/01/2026 18:57, Alper Gun wrote:
> On Wed, Dec 17, 2025 at 2:13 AM Steven Price <steven.price@arm.com> wrote:
>>
>> Creating a realm involves first creating a realm descriptor (RD). This
>> involves passing the configuration information to the RMM. Do this as
>> part of realm_ensure_created() so that the realm is created when it is
>> first needed.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> New patch for v12
>> ---
>> arch/arm64/kvm/rmi.c | 117 ++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 115 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
>> index b51e68e56d56..18edc7eeb5fa 100644
>> --- a/arch/arm64/kvm/rmi.c
>> +++ b/arch/arm64/kvm/rmi.c
>> @@ -500,6 +500,106 @@ static void realm_unmap_shared_range(struct kvm *kvm,
>> start, end);
>> }
>>
>> +/* Calculate the number of s2 root rtts needed */
>> +static int realm_num_root_rtts(struct realm *realm)
>> +{
>> + unsigned int ipa_bits = realm->ia_bits;
>> + unsigned int levels = 4 - get_start_level(realm);
>> + unsigned int sl_ipa_bits = levels * (RMM_PAGE_SHIFT - 3) +
>> + RMM_PAGE_SHIFT;
>> +
>> + if (sl_ipa_bits >= ipa_bits)
>> + return 1;
>> +
>> + return 1 << (ipa_bits - sl_ipa_bits);
>> +}
>> +
>> +static int realm_create_rd(struct kvm *kvm)
>> +{
>> + struct realm *realm = &kvm->arch.realm;
>> + struct realm_params *params = realm->params;
>> + void *rd = NULL;
>> + phys_addr_t rd_phys, params_phys;
>> + size_t pgd_size = kvm_pgtable_stage2_pgd_size(kvm->arch.mmu.vtcr);
>> + int i, r;
>> + int rtt_num_start;
>> +
>> + realm->ia_bits = VTCR_EL2_IPA(kvm->arch.mmu.vtcr);
>> + rtt_num_start = realm_num_root_rtts(realm);
>> +
>> + if (WARN_ON(realm->rd || !realm->params))
>> + return -EEXIST;
>> +
>> + if (pgd_size / RMM_PAGE_SIZE < rtt_num_start)
>> + return -EINVAL;
>> +
>> + rd = (void *)__get_free_page(GFP_KERNEL);
>> + if (!rd)
>> + return -ENOMEM;
>> +
>> + rd_phys = virt_to_phys(rd);
>> + if (rmi_granule_delegate(rd_phys)) {
>> + r = -ENXIO;
>> + goto free_rd;
>> + }
>> +
>> + for (i = 0; i < pgd_size; i += RMM_PAGE_SIZE) {
>> + phys_addr_t pgd_phys = kvm->arch.mmu.pgd_phys + i;
>> +
>> + if (rmi_granule_delegate(pgd_phys)) {
>> + r = -ENXIO;
>> + goto out_undelegate_tables;
>> + }
>> + }
>> +
>> + params->s2sz = VTCR_EL2_IPA(kvm->arch.mmu.vtcr);
>> + params->rtt_level_start = get_start_level(realm);
>> + params->rtt_num_start = rtt_num_start;
>> + params->rtt_base = kvm->arch.mmu.pgd_phys;
>> + params->vmid = realm->vmid;
>
> I don't see a way to configure rpv and hash_algo anymore. I assume they
> are gone for a minimal userspace interface. Will there be a way to set
> them going forward?
Yes the intention is that the uAPI will be extended in the future to
allow these to be configured. This would be by exposing new capability
flags and allowing the VMM to set the capability. This ensures that a
basic VMM doesn't need to worry about them, but a more featured VMM can
provide support for configuration.
This series is already rather long so I've attempted to drop optional
parts to keep the complexity down while still providing something
"useful" (i.e. can launch a realm guest and there's some meaningful
extra security/attestation over a normal VM). There's loads of extra
features in the spec which will come later.
Thanks,
Steve
>> +
>> + params_phys = virt_to_phys(params);
>> +
>> + if (rmi_realm_create(rd_phys, params_phys)) {
>> + r = -ENXIO;
>> + goto out_undelegate_tables;
>> + }
>> +
>> + if (WARN_ON(rmi_rec_aux_count(rd_phys, &realm->num_aux))) {
>> + WARN_ON(rmi_realm_destroy(rd_phys));
>> + r = -ENXIO;
>> + goto out_undelegate_tables;
>> + }
>> +
>> + realm->rd = rd;
>> + WRITE_ONCE(realm->state, REALM_STATE_NEW);
>> + /* The realm is up, free the parameters. */
>> + free_page((unsigned long)realm->params);
>> + realm->params = NULL;
>> +
>> + return 0;
>> +
>> +out_undelegate_tables:
>> + while (i > 0) {
>> + i -= RMM_PAGE_SIZE;
>> +
>> + phys_addr_t pgd_phys = kvm->arch.mmu.pgd_phys + i;
>> +
>> + if (WARN_ON(rmi_granule_undelegate(pgd_phys))) {
>> + /* Leak the pages if they cannot be returned */
>> + kvm->arch.mmu.pgt = NULL;
>> + break;
>> + }
>> + }
>> + if (WARN_ON(rmi_granule_undelegate(rd_phys))) {
>> + /* Leak the page if it isn't returned */
>> + return r;
>> + }
>> +free_rd:
>> + free_page((unsigned long)rd);
>> + return r;
>> +}
>> +
>> static int realm_unmap_private_page(struct realm *realm,
>> unsigned long ipa,
>> unsigned long *next_addr)
>> @@ -803,8 +903,21 @@ static int realm_init_ipa_state(struct kvm *kvm,
>>
>> static int realm_ensure_created(struct kvm *kvm)
>> {
>> - /* Provided in later patch */
>> - return -ENXIO;
>> + int ret;
>> +
>> + switch (kvm_realm_state(kvm)) {
>> + case REALM_STATE_NONE:
>> + break;
>> + case REALM_STATE_NEW:
>> + return 0;
>> + case REALM_STATE_DEAD:
>> + return -ENXIO;
>> + default:
>> + return -EBUSY;
>> + }
>> +
>> + ret = realm_create_rd(kvm);
>> + return ret;
>> }
>>
>> static int set_ripas_of_protected_regions(struct kvm *kvm)
>> --
>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH v12 06/46] arm64: RMI: Define the user ABI
From: Steven Price @ 2026-01-26 9:37 UTC (permalink / raw)
To: Suzuki K Poulose, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <a837d104-5df6-40bc-b129-eaf39fdab482@arm.com>
On 23/01/2026 16:47, Suzuki K Poulose wrote:
> Hi Steven
>
> On 17/12/2025 10:10, Steven Price wrote:
>> There is one CAP which identified the presence of CCA, and two ioctls.
>> One ioctl is used to populate memory and the other is used when user
>> space is providing the PSCI implementation to identify the target of the
>> operation.
>>
>
> Could we split these changes to the corresponding implementation patches
> ? That might give us a full picture of how these UAPIs fit in the bigger
> picture.
I could do that, but I was deliberately keeping this as a patch which
contains the uABI interface so that the whole uABI is visible in one
place. I was trying to reduce the amount to review for those who aren't
so interested in the implementation details (especially for this series
where we know it's going to change somewhat with the move to RMM v2.0).
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Changes since v11:
>> * Completely reworked to be more implicit. Rather than having explicit
>> CAP operations to progress the realm construction these operations
>> are done when needed (on populating and on first vCPU run).
>> * Populate and PSCI complete are promoted to proper ioctls.
>> Changes since v10:
>> * Rename symbols from RME to RMI.
>> Changes since v9:
>> * Improvements to documentation.
>> * Bump the magic number for KVM_CAP_ARM_RME to avoid conflicts.
>> Changes since v8:
>> * Minor improvements to documentation following review.
>> * Bump the magic numbers to avoid conflicts.
>> Changes since v7:
>> * Add documentation of new ioctls
>> * Bump the magic numbers to avoid conflicts
>> Changes since v6:
>> * Rename some of the symbols to make their usage clearer and avoid
>> repetition.
>> Changes from v5:
>> * Actually expose the new VCPU capability (KVM_ARM_VCPU_REC) by bumping
>> KVM_VCPU_MAX_FEATURES - note this also exposes KVM_ARM_VCPU_HAS_EL2!
>> ---
>> Documentation/virt/kvm/api.rst | 57 ++++++++++++++++++++++++++++++++++
>> include/uapi/linux/kvm.h | 23 ++++++++++++++
>> 2 files changed, 80 insertions(+)
>>
>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/
>> api.rst
>> index 01a3abef8abb..2d5dc7e48954 100644
>> --- a/Documentation/virt/kvm/api.rst
>> +++ b/Documentation/virt/kvm/api.rst
>> @@ -6517,6 +6517,54 @@ the capability to be present.
>> `flags` must currently be zero.
>> +4.144 KVM_ARM_VCPU_RMI_PSCI_COMPLETE
>> +------------------------------------
>> +
>> +:Capability: KVM_CAP_ARM_RMI
>> +:Architectures: arm64
>> +:Type: vcpu ioctl
>> +:Parameters: struct kvm_arm_rmi_psci_complete (in)
>> +:Returns: 0 if successful, < 0 on error
>> +
>> +::
>> +
>> + struct kvm_arm_rmi_psci_complete {
>> + __u64 target_mpidr;
>> + __u32 psci_status;
>> + __u32 padding[3];
>> + };
>> +
>> +Where PSCI functions are handled by user space, the RMM needs to be
>> informed of
>> +the target of the operation using `target_mpidr`, along with the status
>> +(`psci_status`). The RMM v1.0 specification defines two functions
>> that require
>> +this call: PSCI_CPU_ON and PSCI_AFFINITY_INFO.
>> +
>> +If the kernel is handling PSCI then this is done automatically and
>> the VMM
>> +doesn't need to call this ioctl.
>> +
>> +4.145 KVM_ARM_RMI_POPULATE
>> +--------------------------
>> +
>> +:Capability: KVM_CAP_ARM_RMI
>> +:Architectures: arm64
>> +:Type: vm ioctl
>> +:Parameters: struct kvm_arm_rmi_populate (in)
>> +:Returns: number of bytes populated, < 0 on error
>> +
>> +::
>> +
>> + struct kvm_arm_rmi_populate {
>> + __u64 base;
>> + __u64 size;
>> + __u64 source_uaddr;
>> + __u32 flags;
>> + __u32 reserved;
>> + };
>> +
>> +Populate a region of protected address space by copying the data from
>> the user
>> +space pointer provided. This is only valid before any VCPUs have been
>> run.
>> +The ioctl might not populate the entire region and user space may
>> have to
>> +repeatedly call it (with updated pointers) to populate the entire
>> region.
>
> It may be a good idea to spill out the restrictions on calling this,
> right ? We expect that the source_uaddr is a separate memory area
> from the "DRAM" (in shared mode) ?
Yes - I'd tried to say that by mentioning it's a "user space pointer",
but I could make that more explicit.
> Can this be called before/after converting the entire memory of the
> Guest to Private ? I believe, it must be done after the "initial
> change all of DRAM to private" ?
It can be called before or after setting RIPAS and it implicitly sets
RIPAS to RAM (I'll add something to make that explicit).
With RMM v1.0 there's an ugly problem that INIT_RIPAS fails on a region
which is already RIPAS RAM. This should be fixed with RMM v2.0. There's
a workaround in patch 17 currently:
/* FIXME: Ugly hack to skip regions which are
* already RIPAS_RAM
*/
But that should go away.
Note that with this proposed uAPI there is no mechanism for user space
to directly set the RIPAS - it's assumed that all guestmem_fd regions
should be set to RIPAS RAM at the time of the first VCPU run - which
means the VMM doesn't need to do anything special.
In the future we could consider a guestmem_fd flag or extra ioctl to
allow the VMM to control RIPAS at a finer granularity. But so far we
don't seem to have any compelling reason to expose that.
Thanks,
Steve
> Suzuki
>
>> .. _kvm_run:
>> @@ -8765,6 +8813,15 @@ helpful if user space wants to emulate
>> instructions which are not
>> This capability can be enabled dynamically even if VCPUs were already
>> created and are running.
>> +7.47 KVM_CAP_ARM_RMI
>> +--------------------
>> +
>> +:Architectures: arm64
>> +:Target: VM
>> +:Parameters: None
>> +
>> +This capability indicates that support for CCA realms is available.
>> +
>> 8. Other capabilities.
>> ======================
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index dddb781b0507..8e66ba9c81db 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -974,6 +974,7 @@ struct kvm_enable_cap {
>> #define KVM_CAP_GUEST_MEMFD_FLAGS 244
>> #define KVM_CAP_ARM_SEA_TO_USER 245
>> #define KVM_CAP_S390_USER_OPEREXEC 246
>> +#define KVM_CAP_ARM_RMI 247
>> struct kvm_irq_routing_irqchip {
>> __u32 irqchip;
>> @@ -1628,4 +1629,26 @@ struct kvm_pre_fault_memory {
>> __u64 padding[5];
>> };
>> +/* Available with KVM_CAP_ARM_RMI, only for VMs with
>> KVM_VM_TYPE_ARM_REALM */
>> +struct kvm_arm_rmi_psci_complete {
>> + __u64 target_mpidr;
>> + __u32 psci_status;
>> + __u32 padding[3];
>> +};
>> +
>> +#define KVM_ARM_VCPU_RMI_PSCI_COMPLETE _IOW(KVMIO, 0xd6, struct
>> kvm_arm_rmi_psci_complete)
>> +
>> +/* Available with KVM_CAP_ARM_RMI, only for VMs with
>> KVM_VM_TYPE_ARM_REALM */
>> +struct kvm_arm_rmi_populate {
>> + __u64 base;
>> + __u64 size;
>> + __u64 source_uaddr;
>> + __u32 flags;
>> + __u32 reserved;
>> +};
>> +
>> +#define KVM_ARM_RMI_POPULATE_FLAGS_MEASURE (1 << 0)
>> +
>> +#define KVM_ARM_RMI_POPULATE _IOW(KVMIO, 0xd7, struct
>> kvm_arm_rmi_populate)
>> +
>> #endif /* __LINUX_KVM_H */
>
^ permalink raw reply
* Re: [PATCH kernel 2/2] crypto/ccp: Allow multiple streams on the same root bridge
From: Alexey Kardashevskiy @ 2026-01-26 0:44 UTC (permalink / raw)
To: dan.j.williams, linux-crypto
Cc: linux-kernel, Ashish Kalra, Tom Lendacky, John Allen, Herbert Xu,
David S. Miller, x86, linux-coco, Pratik R . Sampat
In-Reply-To: <6973fd402a74a_309510049@dwillia2-mobl4.notmuch>
On 24/1/26 09:59, dan.j.williams@intel.com wrote:
> Alexey Kardashevskiy wrote:
>> IDE stream IDs are responsibility of a platform and in some cases TSM
>> allocates the numbers. AMD SEV TIO though leaves it to the host OS.
>> Mistakenly stream ID is hard coded to be the same as a traffic class.
>
> I scratched my head at this comment, but now realize that you are saying
> the existing code used the local @tc, not that the hardware stream ID is
> in any way related to traffic class, right?
When I did that in the first place, I also wanted to try different traffic classes so I just took a shortcut here.
> It would help to detail what the end user visible effects of this bug
> are. The TSM framework does not allow for multiple streams per PF, so I
> wonder what scenario is being fixed?
There is no way in the current upstream code to specify this TC so the only visible effect is that 2 devices under the same bridge can work now, previously the second device would fail to allocate a stream.
> Lastly, are you expecting tsm.git#fixes to pick this up? I am assuming
> that this goes through crypto.git and tsm.git can just stay focused on
> core fixes.
I was kinda hoping that Tom acks these (as he did) and you could take them. Thanks,
--
Alexey
^ permalink raw reply
* Re: [PATCH v1 12/14] x86/boot: tweak a20.c for better code generation
From: H. Peter Anvin @ 2026-01-24 23:40 UTC (permalink / raw)
To: David Laight
Cc: Maciej W. Rozycki, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Uros Bizjak, Petr Mladek, Andrew Morton, Kees Cook,
Peter Zijlstra (Intel), Nathan Chancellor, Kiryl Shutsemau,
Rick Edgecombe, linux-kernel, linux-coco, x86
In-Reply-To: <48826D19-02E6-49D9-941C-C5C374CD1524@zytor.com>
On January 24, 2026 3:16:18 PM PST, "H. Peter Anvin" <hpa@zytor.com> wrote:
>On January 24, 2026 3:07:41 PM PST, David Laight <david.laight.linux@gmail.com> wrote:
>>On Fri, 23 Jan 2026 20:24:55 -0800
>>"H. Peter Anvin" <hpa@zytor.com> wrote:
>>
>>> On 2026-01-23 19:00, Maciej W. Rozycki wrote:
>>> > On Wed, 21 Jan 2026, David Laight wrote:
>>> >
>>> >> No loops needed.
>>> >
>>> > A loop is needed because there can be a considerable delay from issuing
>>> > the I/O request to flip the A20 gate till the circuitry responding. This
>>> > is particularly true with the command issued to the 8042 device, which is
>>> > a microcontroller running its own firmware that needs it time to process
>>> > an incoming request to drive one of the microcontroller's GPIOs. There
>>> > was a reason for port 0x92 circuitry later added to the PC architecture
>>> > with the IBM PS/2 being called the "fast A20 gate".
>>> >
>>>
>>> Indeed. I thought I had responded to this already but I hadn't, apparently.
>>>
>>> Note that the "long" delay is 2^21 loops! That number wasn't taken out of the
>>> air, either; we found machines that actually needed that many iterations.
>>
>>Ok, so you need a loop because it might take ages for the value read from
>>0x1000200 to change.
>>But there is no need to keep changing the value.
>>The comments in the code don't really stress that.
>>
>>> In the case where A20 is enabled already, the loop terminates on either the
>>> first or second iteration (the second iteration is when the value at 0x1000200
>>> is exactly 1 higher than the value at 0x200.
>>>
>>> Modern machines (Nehalem+) already have A20 enabled, and most machines of the
>>> i686+ generation implement int 0x15 function 0x2401.
>>
>>I know some of the history.
>>And just read some more of the gory details...
>>
>>A20 being disabled is there to make a 286 compatible with the older 8086 PCs
>>and any software that relied on address wrapping (rather than using it to get
>>an extra ~64kB in real mode).
>>That would be for dos and win 3.11...
>>
>>The only 8088 and 286 cpu I used were on IO cards.
>>
>>>
>>> -hpa
>>>
>>
>
>No, there is a reason to keep changing the value: you have no idea what is currently stored in that memory, *and you have no way of knowing*.
>
>Whatever value you write might purely accidentally be the value that already is stored at that memory location.
The other thing about this code is that performance is irrelevant – it is a busy wait loop! – but consistency (hence the io_delay) and code size matter.
^ permalink raw reply
* Re: [PATCH v1 12/14] x86/boot: tweak a20.c for better code generation
From: H. Peter Anvin @ 2026-01-24 23:16 UTC (permalink / raw)
To: David Laight
Cc: Maciej W. Rozycki, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Uros Bizjak, Petr Mladek, Andrew Morton, Kees Cook,
Peter Zijlstra (Intel), Nathan Chancellor, Kiryl Shutsemau,
Rick Edgecombe, linux-kernel, linux-coco, x86
In-Reply-To: <20260124230741.2b94b14c@pumpkin>
On January 24, 2026 3:07:41 PM PST, David Laight <david.laight.linux@gmail.com> wrote:
>On Fri, 23 Jan 2026 20:24:55 -0800
>"H. Peter Anvin" <hpa@zytor.com> wrote:
>
>> On 2026-01-23 19:00, Maciej W. Rozycki wrote:
>> > On Wed, 21 Jan 2026, David Laight wrote:
>> >
>> >> No loops needed.
>> >
>> > A loop is needed because there can be a considerable delay from issuing
>> > the I/O request to flip the A20 gate till the circuitry responding. This
>> > is particularly true with the command issued to the 8042 device, which is
>> > a microcontroller running its own firmware that needs it time to process
>> > an incoming request to drive one of the microcontroller's GPIOs. There
>> > was a reason for port 0x92 circuitry later added to the PC architecture
>> > with the IBM PS/2 being called the "fast A20 gate".
>> >
>>
>> Indeed. I thought I had responded to this already but I hadn't, apparently.
>>
>> Note that the "long" delay is 2^21 loops! That number wasn't taken out of the
>> air, either; we found machines that actually needed that many iterations.
>
>Ok, so you need a loop because it might take ages for the value read from
>0x1000200 to change.
>But there is no need to keep changing the value.
>The comments in the code don't really stress that.
>
>> In the case where A20 is enabled already, the loop terminates on either the
>> first or second iteration (the second iteration is when the value at 0x1000200
>> is exactly 1 higher than the value at 0x200.
>>
>> Modern machines (Nehalem+) already have A20 enabled, and most machines of the
>> i686+ generation implement int 0x15 function 0x2401.
>
>I know some of the history.
>And just read some more of the gory details...
>
>A20 being disabled is there to make a 286 compatible with the older 8086 PCs
>and any software that relied on address wrapping (rather than using it to get
>an extra ~64kB in real mode).
>That would be for dos and win 3.11...
>
>The only 8088 and 286 cpu I used were on IO cards.
>
>>
>> -hpa
>>
>
No, there is a reason to keep changing the value: you have no idea what is currently stored in that memory, *and you have no way of knowing*.
Whatever value you write might purely accidentally be the value that already is stored at that memory location.
^ permalink raw reply
* Re: [PATCH v1 12/14] x86/boot: tweak a20.c for better code generation
From: David Laight @ 2026-01-24 23:07 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Maciej W. Rozycki, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Uros Bizjak, Petr Mladek, Andrew Morton, Kees Cook,
Peter Zijlstra (Intel), Nathan Chancellor, Kiryl Shutsemau,
Rick Edgecombe, linux-kernel, linux-coco, x86
In-Reply-To: <981124b5-040e-400b-9912-15a65fdfdfdd@zytor.com>
On Fri, 23 Jan 2026 20:24:55 -0800
"H. Peter Anvin" <hpa@zytor.com> wrote:
> On 2026-01-23 19:00, Maciej W. Rozycki wrote:
> > On Wed, 21 Jan 2026, David Laight wrote:
> >
> >> No loops needed.
> >
> > A loop is needed because there can be a considerable delay from issuing
> > the I/O request to flip the A20 gate till the circuitry responding. This
> > is particularly true with the command issued to the 8042 device, which is
> > a microcontroller running its own firmware that needs it time to process
> > an incoming request to drive one of the microcontroller's GPIOs. There
> > was a reason for port 0x92 circuitry later added to the PC architecture
> > with the IBM PS/2 being called the "fast A20 gate".
> >
>
> Indeed. I thought I had responded to this already but I hadn't, apparently.
>
> Note that the "long" delay is 2^21 loops! That number wasn't taken out of the
> air, either; we found machines that actually needed that many iterations.
Ok, so you need a loop because it might take ages for the value read from
0x1000200 to change.
But there is no need to keep changing the value.
The comments in the code don't really stress that.
> In the case where A20 is enabled already, the loop terminates on either the
> first or second iteration (the second iteration is when the value at 0x1000200
> is exactly 1 higher than the value at 0x200.
>
> Modern machines (Nehalem+) already have A20 enabled, and most machines of the
> i686+ generation implement int 0x15 function 0x2401.
I know some of the history.
And just read some more of the gory details...
A20 being disabled is there to make a 286 compatible with the older 8086 PCs
and any software that relied on address wrapping (rather than using it to get
an extra ~64kB in real mode).
That would be for dos and win 3.11...
The only 8088 and 286 cpu I used were on IO cards.
>
> -hpa
>
^ permalink raw reply
* Re: [PATCH v1 12/14] x86/boot: tweak a20.c for better code generation
From: H. Peter Anvin @ 2026-01-24 4:24 UTC (permalink / raw)
To: Maciej W. Rozycki, David Laight
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Uros Bizjak, Petr Mladek, Andrew Morton, Kees Cook,
Peter Zijlstra (Intel), Nathan Chancellor, Kiryl Shutsemau,
Rick Edgecombe, linux-kernel, linux-coco, x86
In-Reply-To: <alpine.DEB.2.21.2601240244460.6421@angie.orcam.me.uk>
On 2026-01-23 19:00, Maciej W. Rozycki wrote:
> On Wed, 21 Jan 2026, David Laight wrote:
>
>> No loops needed.
>
> A loop is needed because there can be a considerable delay from issuing
> the I/O request to flip the A20 gate till the circuitry responding. This
> is particularly true with the command issued to the 8042 device, which is
> a microcontroller running its own firmware that needs it time to process
> an incoming request to drive one of the microcontroller's GPIOs. There
> was a reason for port 0x92 circuitry later added to the PC architecture
> with the IBM PS/2 being called the "fast A20 gate".
>
Indeed. I thought I had responded to this already but I hadn't, apparently.
Note that the "long" delay is 2^21 loops! That number wasn't taken out of the
air, either; we found machines that actually needed that many iterations.
In the case where A20 is enabled already, the loop terminates on either the
first or second iteration (the second iteration is when the value at 0x1000200
is exactly 1 higher than the value at 0x200.
Modern machines (Nehalem+) already have A20 enabled, and most machines of the
i686+ generation implement int 0x15 function 0x2401.
-hpa
^ permalink raw reply
* Re: [PATCH v1 12/14] x86/boot: tweak a20.c for better code generation
From: Maciej W. Rozycki @ 2026-01-24 3:00 UTC (permalink / raw)
To: David Laight
Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Uros Bizjak, Petr Mladek, Andrew Morton, Kees Cook,
Peter Zijlstra (Intel), Nathan Chancellor, Kiryl Shutsemau,
Rick Edgecombe, linux-kernel, linux-coco, x86
In-Reply-To: <20260121114911.6adc2838@pumpkin>
On Wed, 21 Jan 2026, David Laight wrote:
> No loops needed.
A loop is needed because there can be a considerable delay from issuing
the I/O request to flip the A20 gate till the circuitry responding. This
is particularly true with the command issued to the 8042 device, which is
a microcontroller running its own firmware that needs it time to process
an incoming request to drive one of the microcontroller's GPIOs. There
was a reason for port 0x92 circuitry later added to the PC architecture
with the IBM PS/2 being called the "fast A20 gate".
Maciej
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox