Concurrent firmware update (CFW update) in IBM Z and IBM Power systems is a mechanism that allows firmware to be updated while the system continues running workloads, without requiring a full shutdown or reboot of the entire machine.

The core idea is:

Update firmware in a rolling, partitioned, and highly controlled way, so that only a small subset of hardware components is updated at any time while the rest of the system keeps operating normally.

1. Core idea

Instead of:

Stop system → update firmware → reboot → resume

IBM uses:

Run system → isolate component → update firmware → reintegrate → repeat

👉 This is “non-disruptive, staged firmware replacement”.

2. What gets updated concurrently

Firmware updates may apply to:

• CPU microcode
• memory controller firmware
• I/O adapters (PCIe, channel adapters)
• hypervisor firmware (PR/SM / PowerVM)
• service processor firmware
• crypto subsystem firmware (CPACF/Crypto Express)

3. Key requirement: system partitioning

Concurrent updates rely on strict isolation:

A. Logical partitioning (LPARs)

• workloads are separated
• some partitions remain active while others are migrated or paused

B. Redundant hardware paths

• alternate CPUs, I/O paths, memory controllers available

C. Hypervisor control layer

• PR/SM (IBM Z) or PowerVM (IBM Power) coordinates updates

4. Step-by-step concurrent firmware update flow

Step 1: Update preparation

System:

• validates firmware package signature
• checks compatibility
• determines affected components

Step 2: Workload quiescing (partial)

• workloads on target hardware segment are drained or migrated
• not the whole system, only affected domain

Step 3: Isolation of target component

Firmware marks component as:

• “update-safe state”
• no active execution or I/O allowed

Example:

• one CPU drawer
• one I/O adapter group
• one memory controller domain

Step 4: Firmware loading

• new firmware is loaded into isolated hardware region
• verified using cryptographic signatures

Step 5: Execution switch-over

• component restarts internally with new firmware
• state is reinitialized safely
• hardware rejoins system fabric

Step 6: Reintegration

• updated component is re-added to active pool
• workloads resume or are redistributed

Step 7: Rolling update continues

• next component group is updated
• process repeats until complete

5. Why downtime is not required

Because IBM systems are built with:

A. Redundancy everywhere

• multiple CPUs
• multiple I/O paths
• spare capacity in memory and processing

B. Live workload migration

• threads and I/O can move between resources

C. Hypervisor-level orchestration

• PR/SM or PowerVM ensures safe coordination

6. Key enabling technologies

A. Partitioned architecture

• hardware is already logically segmented

B. Dynamic deconfiguration

• faulty or updating components can be removed live

C. Firmware staging area

• firmware is loaded and validated before activation

D. Checkpointing of hardware state

• CPU and I/O state preserved during update transitions

7. Special case: CPU microcode updates

CPU updates are handled carefully:

• one core or chip segment updated at a time
• other cores continue execution
• workloads are migrated away temporarily

👉 avoids system-wide CPU halt

8. I/O firmware updates

For I/O adapters:

• traffic is rerouted to alternate paths
• adapter is temporarily taken offline
• firmware is updated and reactivated

9. Role of service processor

The service processor:

• orchestrates update sequencing
• ensures safety checks
• monitors component health
• triggers rollback if failure occurs

10. Rollback protection

If update fails:

• firmware automatically reverts to previous version
• system continues using stable configuration

11. Impact on workloads

During update:

• minimal performance impact
• slight redistribution of workload
• no application restart required

After update:

• system runs with new firmware transparently

12. Simple mental model

Think of concurrent firmware update as:

A highly coordinated rolling replacement process where individual hardware components are temporarily taken offline, upgraded with new firmware, tested, and reintroduced into the system while all other components continue processing workloads uninterrupted.

13. Key takeaway

Concurrent firmware updates in IBM systems work by:

• isolating hardware components dynamically
• migrating workloads away from update targets
• updating firmware in a staged, rolling manner
• reintegrating components without rebooting the system
• leveraging system-wide redundancy and hypervisor control

👉 Result: firmware can be upgraded without stopping the enterprise system