linux-stable.git/drivers/virt/coco, branch v7.2.6

virt: arm-cca-guest: use migrate_disable() for attestation token requests

2026-09-14T11:39:41+00:00

[ Upstream commit 24f55f511b9e1c19dc48d11bfe0dc60c86bdb376 ]

The RSI attestation token init and continue calls must be issued from
the same CPU. arm_cca_report_new() currently snapshots the CPU number
and uses smp_call_function_single() to issue those calls on that CPU.

With CONFIG_DEBUG_PREEMPT=y, the smp_processor_id() call used for the
snapshot triggers a debug splat [0] because it runs in preemptible
context. The snapshot does not pin the task to that CPU; it is only used
to choose the target CPU for smp_call_function_single(), which can fail
if that CPU is no longer available.

Use migrate_disable() and issue the token init and continue operations
directly, without the smp_call_function_single() callbacks. This keeps
the token request sequence on the same CPU while preserving a sleepable
context for the GFP_KERNEL allocations needed after the init call.

[0]
 BUG: using smp_processor_id() in preemptible [00000000] code: cca-workload-at/264
 caller is debug_smp_processor_id+0x20/0x30
 CPU: 0 UID: 0 PID: 264 Comm: cca-workload-at Not tainted 7.1.0-rc1-00044-g55542ab273f2 #80 PREEMPT(lazy)
 Hardware name: linux,dummy-virt (DT)
 Call trace:
  [...]
  check_preemption_disabled+0xd8/0xf8
  debug_smp_processor_id+0x20/0x30
  arm_cca_report_new+0x48/0x278
  tsm_report_read+0x154/0x1f8
  tsm_report_outblob_read+0x20/0x38
  configfs_bin_read_iter+0x118/0x208
  vfs_read+0x220/0x318
  [...]

Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms")
Signed-off-by: Kohei Enju 
Reviewed-by: Suzuki K Poulose 
Tested-by: Suzuki K Poulose 
Reviewed-by: Gavin Shan 
Reviewed-by: Steven Price 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

drivers/virt: pkvm: Fix end calculation in mmio_guard_ioremap_hook()

2026-07-17T17:49:12+00:00

Sashiko (locally) reports a logical issues in mmio_guard_ioremap_hook()

mmio_guard_ioremap_hook() attempts to handle unaligned addresses and
sizes. However, aligning the start address before adding the size, might
shift the end to the page before.

Fixes: 0f1269495800 ("drivers/virt: pkvm: Intercept ioremap using pKVM MMIO_GUARD hypercall")
Signed-off-by: Mostafa Saleh 
Reviewed-by: Catalin Marinas 
Tested-by: Aneesh Kumar K.V (Arm) 
Signed-off-by: Will Deacon

Replace by more specific (c files)

2026-07-03T05:38:17+00:00

Replace the #include of  by the more specific
 where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.

Acked-by: Danilo Krummrich 
Acked-by: Takashi Sakamoto 
Acked-by: Bjorn Helgaas 
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub)

Merge tag 'x86_tdx_for_7.2-rc1' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip

2026-06-16T00:56:12+00:00

Pull x86 TDX updates from Dave Hansen:
 "There are a few cleanups, and some changes that should allow TDX and
  kexec to coexist nicely.

  The biggest change, however, is support for updating the TDX module
  after boot, just like CPU microcode. TDX users really want this
  because it lets them do security updates without tearing things down
  and rebooting.

   - Add TDX module update support

   - Make kexec and TDX finally place nice together

   - Put TDX error codes into a single header"

* tag 'x86_tdx_for_7.2-rc1' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip: (30 commits)
  x86/virt/tdx: Document TDX module update
  x86/virt/tdx: Enable TDX module runtime updates
  x86/virt/tdx: Refresh TDX module version after update
  coco/tdx-host: Lock out module updates when reading version
  x86/virt/seamldr: Add module update locking
  x86/virt/tdx: Restore TDX module state
  x86/virt/seamldr: Initialize the newly-installed TDX module
  x86/virt/seamldr: Install a new TDX module
  x86/virt/tdx: Reset software states during TDX module shutdown
  x86/virt/seamldr: Shut down the current TDX module
  x86/virt/seamldr: Abort updates after a failed step
  x86/virt/seamldr: Introduce skeleton for TDX module updates
  x86/virt/seamldr: Allocate and populate a module update request
  coco/tdx-host: Implement firmware upload sysfs ABI for TDX module updates
  coco/tdx-host: Don't expose P-SEAMLDR information on CPUs with erratum
  coco/tdx-host: Expose P-SEAMLDR information via sysfs
  x86/virt/seamldr: Add a helper to retrieve P-SEAMLDR information
  x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs
  coco/tdx-host: Expose TDX module version
  coco/tdx-host: Introduce a "tdx_host" device
  ...

coco/tdx-host: Lock out module updates when reading version

2026-06-03T15:59:44+00:00

The TDX module version is currently stashed in some global variables
and dumped out to sysfs without locking. This works fine when the
version is static and never changes.

But with runtime module updates, the TDX module version can change.
Some kind of locking is needed. Barring this, userspace could
theoretically see a strange torn module version that is some
Frankenstein version from from two different updates.

Use the new module update lock/unlock to prevent updates while
trying to read the version.

Don't be fussy about it. There's no need to snapshot the version or do
READ_ONCE(), or minimize lock holding times. sysfs_emit() does not
sleep. Also note that the lock/unlock are backed by
preempt_dis/enable() which are really cheap CPU-local operations.
This is not a heavyweight lock.

Signed-off-by: Dave Hansen

coco/tdx-host: Implement firmware upload sysfs ABI for TDX module updates

2026-06-03T15:14:51+00:00

tl;dr: Select fw_upload for doing TDX module updates. The process of
selecting among available update images is complicated and nuanced. Punt
the selection process out to userspace. One existing userspace
implementation today is the script in the Intel TDX Module Binaries
repository[1].

Long Version:

The kernel supports two primary firmware update mechanisms:
 1. request_firmware() - used by microcode, SEV firmware, hundreds of
			 other drivers
 2. 'struct fw_upload' - used by CXL, FPGA updates, dozens of others

The key difference between is that request_firmware() loads a named file
from the filesystem where the filename is kernel-controlled, while
fw_upload accepts firmware data directly from userspace.

TDX module firmware update selection policy is too complex for the kernel.
Leave it to userspace and use fw_upload.

Add a skeleton fw_upload implementation to be fleshed out in subsequent
patches.

Refactor the sysfs visiblity attribute function so it can be used as a
more generic flag for the presence of viable runtime update support.

Why fw_upload instead of request_firmware()?
============================================

Selecting a TDX module update image is not a simple "load the latest"
decision. Userspace needs to choose an image that is compatible with both
the platform and the currently running module.

Some constraints are hard requirements:

a. Module version series are platform-specific. For example, the 1.5.x
   series runs on Sapphire Rapids but not Granite Rapids, which needs
   2.0.x.

b. Updates are also constrained by version distance. A 1.5.6 module
   might permit updates to 1.5.7 but not to 1.5.50.

There may also be userspace policy choices:

c. Decide the update direction: upgrade or downgrade

d. Choose whether to optimize for fewer updates or smaller version
   steps, for example, 1.2.3=>1.2.5 versus 1.2.3=>1.2.4=>1.2.5.

Given that complexity, leave module selection to userspace and use
fw_upload.

1. https://github.com/intel/confidential-computing.tdx.tdx-module.binaries/blob/main/version_select_and_load.py

[ dhansen: add version script link, add more explanation of code moves,
 	   fix some minor whitespace issues ]

Signed-off-by: Chao Gao 
Signed-off-by: Dave Hansen 
Reviewed-by: Tony Lindgren 
Reviewed-by: Kai Huang 
Reviewed-by: Kiryl Shutsemau (Meta) 
Link: https://lore.kernel.org/kvm/01fc8946-eb84-46fa-9458-f345dd3f6033@intel.com/
Link: https://patch.msgid.link/20260520133909.409394-13-chao.gao@intel.com

coco/tdx-host: Don't expose P-SEAMLDR information on CPUs with erratum

2026-06-03T15:14:51+00:00

TDX-capable CPUs clobber the current VMCS on P-SEAMLDR calls. Clearing
the current VMCS behind KVM's back breaks KVM.

Future CPUs will fix this by preserving the current VMCS across
P-SEAMLDR calls. A future specification update will describe the
VMCS-clearing behavior as an erratum and to state that it does not
occur when IA32_VMX_BASIC[60] is set.

Add a CPU bug bit and refuse to expose P-SEAMLDR information on
affected CPUs.

Use a CPU bug bit to stay consistent with X86_BUG_TDX_PW_MCE. As a
bonus, the bug bit is visible to userspace, which allows userspace to
determine why these sysfs files are not exposed, and it can also be
checked by other kernel components in the future if needed.

== Alternatives ==
Two workarounds were considered but both were rejected:

1. Save/restore the current VMCS around P-SEAMLDR calls. This produces ugly
   assembly code [1] and doesn't play well with #MCE or #NMI if they
   need to use the current VMCS.

2. Move KVM's VMCS tracking logic to the TDX core code, which would break
   the boundary between KVM and the TDX core code [2].

[ dhansen: comment and changelog munging. Add seamldr_call() bug check. ]

Signed-off-by: Chao Gao 
Signed-off-by: Dave Hansen 
Reviewed-by: Kai Huang 
Reviewed-by: Kiryl Shutsemau (Meta) 
Reviewed-by: Rick Edgecombe 
Reviewed-by: Dave Hansen 
Link: https://lore.kernel.org/kvm/fedb3192-e68c-423c-93b2-a4dc2f964148@intel.com/ # [1]
Link: https://lore.kernel.org/kvm/aYIXFmT-676oN6j0@google.com/ # [2]
Link: https://patch.msgid.link/20260520133909.409394-12-chao.gao@intel.com

coco/tdx-host: Expose P-SEAMLDR information via sysfs

2026-06-03T15:14:51+00:00

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
- num_remaining_updates: indicates how many updates can be performed

Expose them as tdx-host device attributes visible only when updates
are supported.

Note that the underlying P-SEAMLDR attributes are available regardless
of update support; this only restricts their visibility to userspace.

Signed-off-by: Chao Gao 
Signed-off-by: Dave Hansen 
Reviewed-by: Kiryl Shutsemau (Meta) 
Reviewed-by: Dave Hansen 
Link: https://patch.msgid.link/20260520133909.409394-11-chao.gao@intel.com

coco/tdx-host: Expose TDX module version

2026-06-03T15:14:51+00:00

For TDX module updates, userspace needs to select compatible update
versions based on the current module version.

For example, the 1.5.x series runs on Sapphire Rapids but not Granite
Rapids, which needs 2.0.x. Updates are also constrained by version
distance, so a 1.5.6 module might permit updates to 1.5.7 but not to
1.5.20.

Start the process of punting the version selection logic to userspace.
Expose the TDX module version in the new faux device.

Define TDX_VERSION_FMT macro for the TDX version format since it will be
used multiple times. Also convert an existing print statement to use it.

== Background ==

For posterity, here's what other firmware mechanisms do:

1. AMD SEV leverages an existing PCI device for the PSP to expose
   metadata. TDX uses a faux device as it doesn't have PCI device
   in its architecture.

2. Microcode uses per-CPU virtual devices to report microcode revisions
   because CPUs can have different revisions. But, there is only a
   single TDX module, so exposing the TDX module version through a global
   TDX faux device is appropriate

3. ARM's CCA implementation isn't in-tree yet, but will likely follow a
   similar faux device approach, though it's unclear whether they need
   to expose firmware version information

[ dhansen: trim changelog ]

Signed-off-by: Chao Gao 
Signed-off-by: Dave Hansen 
Reviewed-by: Binbin Wu 
Reviewed-by: Tony Lindgren 
Reviewed-by: Xu Yilun 
Reviewed-by: Kai Huang 
Reviewed-by: Kiryl Shutsemau (Meta) 
Reviewed-by: Xiaoyao Li 
Reviewed-by: Dave Hansen 
Link: https://lore.kernel.org/all/2025073035-bulginess-rematch-b92e@gregkh/ # [1]
Link: https://patch.msgid.link/20260520133909.409394-8-chao.gao@intel.com

coco/tdx-host: Introduce a "tdx_host" device

2026-06-03T15:14:51+00:00

TDX depends on a platform firmware module that runs on the CPU.
Unlike other CoCo architectures, TDX has no hardware "device"
running the show, just a blob on the CPU.

Create a virtual device to anchor interactions with this platform
firmware. This lets later code:

 - expose metadata: TDX module version, seamldr version, to userspace
   as device attributes

 - implement firmware uploader APIs (which are tied to a device) to
   support TDX module runtime updates

Use a faux device because the TDX module is singular within the system
and has no platform resources. Using a faux device eliminates the need
to create a stub bus.

The call to tdx_get_sysinfo() ensures that the TDX module is ready to
provide services.

Note that AMD has a PCI device for the PSP for SEV and ARM CCA will
likely have a faux device [1].

Thanks to Dan and Yilun for all the help on this one.

[ dhansen: trim changelog ]

Signed-off-by: Chao Gao 
Signed-off-by: Dave Hansen 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Tony Lindgren 
Reviewed-by: Xu Yilun 
Reviewed-by: Kai Huang 
Reviewed-by: Kiryl Shutsemau (Meta) 
Reviewed-by: Xiaoyao Li 
Link: https://lore.kernel.org/all/2025073035-bulginess-rematch-b92e@gregkh/ # [1]
Link: https://patch.msgid.link/20260520133909.409394-7-chao.gao@intel.com