PR/SM (Processor Resource/System Manager) is the firmware hypervisor built into IBM Z that implements Logical Partitions (LPARs) directly in hardware-assisted microcode. Unlike typical software hypervisors, PR/SM is tightly integrated with the processor, memory, and I/O subsystems—giving it very low overhead and extremely strong isolation.

Here’s how it works architecturally:

🔷 1. What PR/SM Really Is

PR/SM is:

• A Type-1 hypervisor implemented in firmware/microcode
• Runs below any operating system
• Certified at very high security levels (e.g., EAL5+)

👉 It creates multiple independent virtual machines (LPARs) on one physical IBM Z system.

🔷 2. LPAR Abstraction Model

Each LPAR appears as a complete physical machine:

• Own CPUs (logical processors)
• Own memory
• Own I/O devices

👉 OS (like z/OS, Linux, z/VM) runs unchanged, as if on bare metal.

🔷 3. CPU Virtualization (Logical Processors)

🔹 Physical vs Logical CPUs

• Physical cores are divided into logical processors
• Each LPAR gets assigned:
  • Dedicated CPUs OR
  • Shared CPUs

🔹 Dispatching

PR/SM schedules logical processors onto physical cores:

• Uses time-slicing for shared CPUs
• Ensures fairness and priority handling

👉 Overhead is extremely low because:

• Scheduling is done in firmware (not software)

🔷 4. Memory Virtualization

🔹 Real Memory Allocation

• Physical memory is divided into regions per LPAR

🔹 Address Translation

• Each LPAR has its own:
  • Virtual → real memory mapping

🔹 Dynamic Changes

• Memory can be added/removed using DLPAR (Dynamic LPAR)

👉 Isolation is hardware-enforced—no LPAR can access another’s memory.

🔷 5. I/O Virtualization (Channel Subsystem Integration)

This is where IBM Z is unique.

🔹 Channel Subsystem Awareness

PR/SM works with the channel subsystem to virtualize I/O:

• Devices are assigned to LPARs via:
  • Subchannels
  • Channel paths

🔹 Direct I/O Access

• LPARs can access devices almost directly
• No heavy hypervisor emulation layer

👉 Result:

• Near-native I/O performance
• Minimal CPU overhead

🔷 6. Resource Allocation Types

🔹 Dedicated Resources

• CPU, memory, I/O fully assigned to one LPAR

🔹 Shared Resources

• CPU pools shared across LPARs
• Managed dynamically

👉 Provides flexibility + efficiency

🔷 7. Hardware-Enforced Isolation

PR/SM ensures strict isolation using:

• Memory protection keys
• Address space separation
• Channel access control

👉 Prevents:

• Data leakage
• Unauthorized access

🔷 8. Weight-Based Resource Management

Each LPAR is assigned a weight:

• Determines CPU share in contention
• Higher weight = more CPU time

👉 Enables:

• Workload prioritization
• Service-level management

🔷 9. Interrupt and Timing Isolation

• Each LPAR gets virtualized interrupts
• PR/SM ensures:
  • One LPAR cannot flood another with interrupts
  • Fair interrupt handling

🔷 10. Integration with Higher-Level Hypervisors

PR/SM can host:

• z/VM
• Linux on Z
• z/OS

👉 This enables:

• Nested virtualization
• Thousands of virtual machines inside LPARs

🔷 11. Security & Compliance

PR/SM provides:

• Strong tenant isolation
• Secure boot integration
• Compliance for banking/government

👉 One reason IBM Z is used for:

• Financial systems
• Government workloads

🔷 🔥 Simple Architecture View

   ┌─────────────────────────────┐
   │           PR/SM             │
   ├──────────┬──────────┬───────┤
   │  LPAR 1  │  LPAR 2  │ LPAR 3│
   │ (z/OS)   │ (Linux)  │ (z/VM)│
   └──────────┴──────────┴───────┘
         │        │        │
     CPU / Memory / I/O (Virtualized)

🔷 🔥 Why PR/SM Is Different from x86 Hypervisors

🔷 🚀 Bottom Line

PR/SM implements LPARs by:

✔ Virtualizing CPU, memory, and I/O in firmware
✔ Integrating deeply with hardware (especially I/O channels)
✔ Enforcing strict isolation at hardware level
✔ Providing dynamic resource allocation
✔ Delivering near-native performance with minimal overhead