Thread Execution Transition via Register File Segmentation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Context switches between guest and hypervisor modes in virtualization systems, particularly in hyper-threaded environments, result in significant latency and security risks due to CPU execution engine conflicts and the need for state saving and restoring, which are computationally expensive and insecure.

Innovation Solution

Implementing an extended instruction set architecture that allows threads to execute in their own security context without actual context switches by using 'setthread' instructions to switch between register files, enabling fast hyper-threaded execution privilege mode transitions without parallelism-related security risks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If context switches are implemented between guest and hypervisor modes in hyper-threaded environments, then privilege mode transition is achieved, but latency increases and security risks arise due to CPU execution engine conflicts and state saving/restoring requirements

Engineering Contradiction:
ImprovesecurityVSAvoidcontext switch latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent segments the CPU state into separate register files for different threads (hyper-thread 0 and hyper-thread 1), allowing each thread to maintain its own execution context independently. This segmentation enables the guest OS to run on one thread while the hypervisor runs on another thread simultaneously, eliminating the need for context switches and associated state saving/restoring operations, thereby reducing latency while maintaining security through isolated register files.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a new dimension of thread identification through setthread instructions that switch between register files associated with different threads. This dimensional change allows the system to transition between guest and hypervisor modes by switching threads rather than performing traditional context switches, eliminating execution engine conflicts and reducing latency while maintaining security boundaries.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Productivity

If traditional context switches are performed between guest and hypervisor, then mode transition is achieved, but computational overhead increases due to state saving and restoring operations

Engineering Contradiction:
Improvevirtualization efficiencyVSAvoidcomputational overhead
Core Design Contradiction:
ProductivityVSUse of energy by moving object

Solution Approach 1:

The patent segments the processor state into separate register files for each thread, allowing the guest OS and hypervisor to maintain independent execution contexts. This eliminates the need for state saving and restoring operations during mode transitions, significantly reducing computational overhead and improving virtualization efficiency while maintaining security through isolated register files.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Each thread maintains its own register files and execution context, allowing it to service its own state requirements without requiring state transfer operations. The setthread instructions enable threads to switch between register files autonomously, eliminating the computational overhead associated with traditional context switch state management operations.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS11169837B2Fast thread execution transition
Publication Date: 2021.11.09 RED HAT INC
  • US11169837B2 patent drawing
  • US11169837B2 patent drawing
  • US11169837B2 patent drawing

AI summary

Systems and methods for thread execution transition are disclosed. An example system includes a memory and a processor with first and second registers. An application and a supervisor are configured to execute on the processor, which suspends execution of a first thread executing the supervisor. One execution state of the first thread is stored in the first register. The application stores a request in a first shared memory location. The application executes on a second thread and another execution state of the second thread is stored in the second register. The processor suspends execution of the second thread and resumes execution of the first thread. The supervisor retrieves data for the request from the first shared memory location, and processes the data, including storing a result to a second shared memory location. The processor suspends execution of the first thread and resumes execution of the second thread.