WO2022120790A1

WO2022120790A1 - Methods and apparatus to mitigate locks in real-time computing environments

Info

Publication number: WO2022120790A1
Application number: PCT/CN2020/135649
Authority: WO
Inventors: Yaozu Dong; Scott OEHRLEIN; Jie Chen
Original assignee: Intel Corporation
Priority date: 2020-12-11
Filing date: 2020-12-11
Publication date: 2022-06-16

Abstract

Methods, apparatus, systems and articles of manufacture to mitigate locks in real-time computing environments are disclosed. An example method includes detecting an indication of an instruction that will trigger a bus lock within a computing system, causing processing to be paused, emulating the instruction without the bus locking, and resuming the processing.

Description

METHODS AND APPARATUS TO MITIGATE LOCKS IN REAL-TIME COMPUTING ENVIRONMENTS

FIELD OF THE DISCLOSURE

This disclosure relates generally to computing devices and, more particularly, to methods and apparatus to avoid locks in real-time computing environments.

BACKGROUND

Real-time computing programs and systems perform operations in environments in which the timing of operation performance is important. For example, some real-time systems must guarantee that they will respond within specified time constraints, often referred to as "deadlines. ” For example, time constraints are often a number of microseconds or a number of milliseconds (although some real-time computing environments may allow for other time constraints) . Many of these real-time systems can be classified as having one or more hard real-time workloads, which means missing a deadline could be considered a complete system failure. Real-time computing systems are widely used in various applications such as a vehicle engine control systems, industrial control systems and process automation, medical equipment such as heart pacemakers, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example computing system that utilizes virtualization

FIG. 2 is a block diagram of an example computing system that includes physical host hardware on which a native operating system executes.

FIG. 3 is a block diagram of an example implementation of the lock mitigation handler of FIG. 1 and/or FIG. 2.

FIGS. 4-6 are a flowcharts representative of example machine readable instructions that may be executed to implement the example lock mitigation handler of FIGS. 1, 2, and/or 3.

FIG. 7 is a block diagram of an example processing platform structured to execute the example machine readable instructions of FIGS. 4-6 to implement the example lock mitigation handler of FIGS. 1, 2, and/or 3 and/or, more generally, the example computing system of FIG. 1 and/or FIG. 2.

FIG. 8 is a block diagram of an example software distribution platform to distribute software (e.g., software corresponding to the example machine readable instructions of FIGS. 4-6) to client devices such as consumers (e.g., for license, sale and/or use) , retailers (e.g., for sale, re-sale, license, and/or sub-license) , and/or original equipment manufacturers (OEMs) (e.g., for inclusion in products to be distributed to, for example, retailers and/or to direct buy customers) .

The figures are not to scale. In general, the same reference numbers will be used throughout the drawing (s) and accompanying written description to refer to the same or like parts. As used herein, connection references (e.g., attached, coupled, connected, and joined) may include intermediate members between the elements referenced by the connection reference and/or relative movement between those elements unless otherwise indicated. As such, connection references do not necessarily infer that two elements are directly connected and/or in fixed relation to each other.

Unless specifically stated otherwise, descriptors such as “first, ” “second, ” “third, ” etc., are used herein without imputing or otherwise indicating any meaning of priority, physical order, arrangement in a list, and/or ordering in any way, but are merely used as labels and/or arbitrary names to distinguish elements for ease of understanding the disclosed examples. In some examples, the descriptor “first” may be used to refer to an element in the detailed description, while the same element may be referred to in a claim with a different descriptor such as “second” or “third. ” In such instances, it should be understood that such descriptors are used merely for identifying those elements distinctly that might, for example, otherwise share a same name.

DETAILED DESCRIPTION

Some computing systems combine real-time computing applications with general purpose best effort applications. For example, both real-time computing applications and general-purpose best effort applications may operate on a single computing device (e.g., a single system on chip (SoC) such as the

SoC using Virtualization Technology) . However, combining real-time and best effort workloads onto the same system (e.g., referred to herein as a consolidated environment or system) brings additional challenges to meet hard real-time requirements of the real-time workload.

In some consolidated environments, a best effort workload may perform operations that block operations associated with a real-time workload from meeting an operation deadline. For example, an atomic operation performed on memory that is split across two cache lines may trigger a split-lock. Such atomic operation always comes from instructions with the LOCK prefix or a XCHG instruction with memory operand. For a real-time system based on a multi-core processor platform, a split-lock access from a sibling best effort workload operating on a first central processing unit (CPU) core will block bus access of a real-time workload operating on a second (sibling) CPU core (e.g., may block access for over 1,000 CPU cycles) . Such blocking could result in a hard, real-time application missing a critical deadline.

Because real-time applications are typically developed in a controlled software environment (e.g., sometimes with safety certification) , it is easier to educate and guide real-time developers to avoid writing code that generates split-locks and other system (e.g., bus) blocking operations. However, since the code running on the best effort workload is often less controlled (possibly download from an application store and often not developed with concern for real-time operation) , it is difficult to control what types of applications may be run on the best effort workload and if they may contain split-locks.

Some systems include a hardware solution to detecting locking operations such as split-locks. For example, a split-lock detection can trigger a fault exception (e.g., an alignment check (#AC) fault exception) to the CPU that issued the instruction that would result in a lock. Such exception may be issued prior to the instruction being executed (e.g., prior to the resulting bus lock) . Such a feature may improve the quality of operation for a real-time system during its testing and debugging timeframe to enable a developer to find and fix split-locks in software. However, for a production system, enabling a detection feature could result in system hangs if an operating system does not know how to handle the exception. On the other hand, disabling the detection feature provides the potential for non-real-time software to execute a split-lock that causes a real-time application to miss a timing deadline.

A typical real-time usage scenario with processors and virtual machines (VMs) in an industrial environment is to consolidate one or more real-time virtual machine (s) (RTVM) and one or more human machine interface (HMI) VM (s) (e.g., a virtual machine hosting an HMI operation system (OS) such as MICROSOFT

OS) . Ideally, the HMI OS should be free of code that generates split-locks and the HMI OS should include support for handling the lock detection exception in case one were to occur. Unfortunately, this ideal scenario is not the reality today. Any commercial OSs designed for use in non-real-time situations (e.g., not designed with real-time solutions in mind) could result in split locks and/or improperly handled exceptions that interfere with a real-time workload in a consolidated system. Furthermore, such a non-real-time OS may be run under less priority and/or security, where a malicious actor may easily invade, take over and run malicious code such as split-lock instructions to intentionally interfere with the operation of the system.

Native operation environments (e.g., an OS executing on a processor outside a virtual environment) present similar problems when real-time and non-real-time applications are run within the OS. For example, a third-party, non-real-time application may not be aware of split-lock issues and may, thus, accidentally or intentionally interfere with the operation of the real-time application.

Methods and apparatus disclosed herein detect that a lock instruction is about to be executed and emulate the lock instruction without locking the system bus. For example, some methods and apparatus temporarily stop all sibling cores within a single domain (e.g., a domain may comprise a virtual machine, an entire native operating environment, etc. ) and execute/emulate the instruction using that would have normally caused a bus-lock. By emulating the instruction (e.g., using atomic operation emulation) without the associated bus-lock occurring, the methods and apparatus disclosed herein may ensure that such instruction can be executed without interfering with the operation of a real-time application. Such emulation enables more robust consolidated systems with real-time and non-real-time domains, and reduces the burden on system integrators to require HMI OS vendors or the developers of non-real-time applications to rewrite their code to remove the instructions resulting in split locks. Furthermore, such execution may be advantageous in any environment (e.g., one that does not necessarily include real-time applications/operations) in which a lock of the system bus may be caused by some instructions, but by design it is desirable for the system to avoid such a lock.

FIG. 1 is a block diagram of an example computing system 100 that utilizes virtualization. The example computing system 100 includes physical host hardware 102 on which a hypervisor 104. The example hypervisor 104 supports a number of virtual machines such as a first virtual machine 108 including an example real-time workload 110 and a second virtual machine 112 including an example non-real-time workload 114. The example hypervisor includes a lock mitigation handler 116 to emulate and/or otherwise handle lock instruction execution (e.g., split-lock instruction execution) in accordance with the methods and apparatus disclosed herein.

The example physical host hardware 102 is an SoC computing device that integrates multiple computing resources (e.g., processing, storage, input/output, etc. ) on an integrated circuit (e.g., on a single substrate, on a single microchip, etc. ) . Alternatively, the physical host hardware 102 may be any type of computing system including any number of communicatively coupled computing components (e.g., logic circuits, processors, memory, storage, input/output, etc. ) . For example, the physical host hardware 102 may be a general-purpose computer including computing components included in a case (e.g., a desktop computer, a laptop, a server, etc. ) . Alternatively, the physical host hardware 102 may be a special purpose computing device such as logic circuitry implementing an industrial control system, a vehicle control system, etc. According to the illustrated example, the physical host hardware 102 includes a virtualization component that facilitates the execution of the hypervisor 104 on the physical host hardware 102. For example, the physical host hardware 102 may implement the INTEL Virtualization Technology. Alternatively, the physical host hardware 102 may be general purpose computing hardware on which a hypervisor may execute without any specialized interfaces to computing hardware.

According to the illustrated example, the physical host hardware 102 includes the capability to raise an exception before processing a lock instruction. For example, a processing resource of the physical host hardware 202 may raise an alignment check (#AC) exception when a split-lock is detected. Alternatively, the physical host hardware may include any other capability for alerting the hypervisor 104 of a lock operation.

The example computing system 100 includes the hypervisor 104 (alternatively referred to as a virtual machine monitor (VMM) ) executing on the physical host hardware 102 to implement a virtualized computing environment to support the

virtual machines

108, 112. The example hypervisor 104 virtualizes the hardware of the physical host hardware 102. The example hypervisor 104 is software stored in a storage resource of the physical host hardware 102 and executed on processing resources of the physical host hardware 102. For example, the hypervisor may be firmware or software. Alternatively, any other implementation of the hypervisor 104 may be utilized.

The first virtual machine 108 and the second virtual machine 112 represent possible virtual machines that operate via the hypervisor 104. Any number of virtual machines may be utilized in other examples. According to the illustrated example, the first virtual machine 108 includes a real-time workload 110 and the second virtual machine 112 executes a non- real-time workload 114. Alternatively, each virtual machine may execute any number and/or type of workload. The

virtual machines

108, 112 may be any type of virtual machine or other type ofvirtualized execution. For example, the hypervisor 104 could be implemented by an operating system that supports containers and the

virtual machines

108, 112 could be containers for execution of workloads. Any other types ofvirtualization technology could be used.

According to the illustrated example, the hypervisor 104 includes the lock mitigation handler 116 to emulate lock instructions (e.g., split-lock instructions) to, among other benefits, prevent bus locks. According to the illustrated example, the lock mitigation handler 116 is implemented by software included in the hypervisor 104. Alternatively, the lock mitigation handler 116 may be implemented in other manners such as firmware of the physical host hardware, dedicated logic circuitry that is coupled to the physical host hardware 102 and/or the hypervisor 104 to support emulation of lock instructions, etc.

The example lock mitigation handler 116 emulates instructions that include locks (e.g., split-lock instructions) to prevent the application of the locks (e.g., to prevent a bus lock caused by the non-real-time workload that might interfere with execution of the real-time workload 110) . According to the illustrated example, the lock mitigation handler 116 listens for exceptions triggered by the physical host hardware. In particular, the lock mitigation handler 116 listens for exceptions that indicate a locking instruction has reached in execution of software (e.g., execution of the non-real-time workload 114) . Instead of allowing the lock instruction to be executed, the example lock mitigation handler 116 stops any other virtual CPUs (e.g., kicks the other virtual CPUs out of non-root mode) (e.g., to prevent them from executing instructions during the emulation) . The lock mitigation handler 116 then removes a lock indication (e.g., a LOCK prefix) from the instruction and executes the single instruction. Once the instruction has been executed, the lock mitigation handler 116 resumes the virtual CPUs that were stopped earlier. The lock mitigation handler 116 then allows the system to continue running. Further details of the operation of the lock mitigation handler 116 are described in conjunction with the block diagram of FIG. 3 and the flowcharts of FIGS. 4-6.

In operation of the computing system 100, when the non-real-time workload 114 attempts to execute an instruction including a lock, the physical host hardware 102 raises an exception. The lock mitigation handler 116 detects the exception and stops other non-real-time virtual CPUs (e.g., to prevent the other non-real-time virtual CPUs from accessing memory associated with the locking instruction until the locking instruction has executed) . The lock mitigation handler 116 then runs the instruction without the associated LOCK. The lock mitigation handler 116 then continues normal operation for the computing system 100 (e.g., including resuming any stopped non-real-time cores. Further details of an example process for emulating the locking instruction without performing the associated LOCK are described in conjunction with FIGS. 4-5.

FIG. 2 is a block diagram of an example computing system 200 that includes physical host hardware 202 on which a native operating system 204 executes. The operating system 204 includes the example lock mitigation handler 116 previously introduced in FIG. 1. An example real-time application 210 executes within the operating system 204. An example non-real-time application 214 also executes within the operating system 204.

The example physical host hardware 202 is an SoC computing device that integrates multiple computing resources (e.g., processing, storage, input/output, etc. ) on an integrated circuit (e.g., on a single substate, on a single microchip, etc. ) . Alternatively, the physical host hardware 202 may be any type of computing system including any number of communicatively coupled computing components (e.g., logic circuits, processors, memory, storage, input/output, etc. ) . For example, the physical host hardware 202 may be a general-purpose computer including computing components included in a case (e.g., a desktop computer, a laptop, a server, etc. ) . Alternatively, the physical host hardware 202 may be a special purpose computing device such as logic circuitry implementing an industrial control system, a vehicle control system, etc.

The example operating system 204 is software that supports the basic functions of the computing system 200 such as scheduling tasks, executing applications, and controlling peripherals and other computing resources. According to the illustrated example, the lock mitigation handler 106 is implemented within a kernel of the operating system. Accordingly, the lock mitigation handler 106 has low-level access to the operations of the operating system 204 to facilitate the mitigation of lock instructions. Alternatively, the lock mitigation handler 106 may be implemented in any other portion of the operating system 204 or any other part of the physical host hardware 202 (e.g., within firmware of the physical host hardware 202, within a processing resource of the physical host hardware 202, a peripheral communicatively coupled to the physical host hardware 202, etc. ) . Further details of the operation of the lock mitigation handler 116 are described in conjunction with the block diagram of FIG. 3 and the flowcharts of FIGS. 4-6.

The example real-time application 210 and the example non-real-time 214 are example software applications executing within the operating system. While only two applications are illustrated, any number of real-time and non-real-time applications may execute within an operating system.

In operation of the computing system 200, when the non-real-time application 214 attempts to execute an instruction including a lock, the physical host hardware 202 raises an exception. The lock mitigation handler 116 detects the exception and stops other non-real-time cores (e.g., to prevent the other non-real-time cores from accessing memory associated the locking instruction until the instruction has been executed) . The lock mitigation handler 116 then runs the instruction without the associated LOCK. The lock mitigation handler 116 then continues normal operation for the computing system 200 (e.g., including resuming any stopped non-real-time cores. Further details of an example process for emulating the locking instruction without performing the associated LOCK are described in conjunction with FIG. 6.

FIG. 3 is a block diagram of an example implementation of the lock mitigation handler 116 of FIG. 1 and/or FIG. 2. The example lock mitigation handler 116 includes an example exception handler 302, an example emulation analyzer 304, and an example instruction emulator 306.

The example exception manager 302 detects an exception thrown by the

physical host hardware

102, 202. For example, the exception may be the Alignment-Check instruction thrown from an IA processor. Alternatively, a different type of exception indicative of a detected locking instruction may be thrown (e.g., a system that employs an ARM processor may throw a different type of exception) . While the illustrated example detects exceptions, the exception manager 302 may detect any other type of indication from the

physical host hardware

102, 202. For example, the exception handler 302 may detect a flag, a message, etc. According to a virtualization example (e.g., the virtualization example illustrated in FIG. 1) , the exception may cause an exit from the virtual machine (e.g., the second virtual machine 112 running the non-real-time workload 114) such that the exception handler 302 can detect the exception to allow the lock mitigation handler 116 to control operations. According to a native execution example (e.g., the example illustrated in FIG. 2) , the exception handler 302 operating in the kernel space of the operating system 204 can trap the exception to allow the lock mitigation handler 116 to control operations. The example exception handler 302 alerts the emulation analyzer 304 of the detected exception (or other information about the locking instruction.

The example emulation analyzer 304 analyzes the exception to determine how to handle the exception. According to the illustrated example, the emulation analyzer 304 analyzes the context of the exception to determine if atomic instruction emulation is to be performed to avoid a bus lock or if the exception should be handled in another manner. For example, if the emulation analyzer 304 determines that a virtual machine that triggered the exception (e.g., the second virtual machine 112) includes a feature to handle locking instructions (e.g., a split-lock exception handling capability) , the emulation analyzer 304 injects the exception back to the virtual machine. Additionally, the emulation analyzer 304 may inject the exception to the virtual machine if the exception is of a type that is not handled by the instruction emulator 306 (e.g., the exception is coming from a legacy Alignment Check) . For example, emulation analyzer may determine the legacy Alignment Check by checking if the instruction pointed to by the current instruction pointer register (RIP) begins with, for example, a LOCK prefix or opcode = 0x86 or 0x87 (e.g., XCHG instruction w/memory operand) ) . For example, an instruction with a LOCK prefix may cause a legacy Alignment Check exception that will be handled by the instruction emulator 306 by removing the LOCK prefix, but such Alignment Check exception will be triggered again when the guest VM re-executes the instruction (even without the LOCK prefix) and, when this occurs and the exception re-triggered after removing the LOCK prefix, the hypervisor 104 then emulation analyzer 304 injects the exception back to the virtual machine. Similarly, in the native example of FIG. 2, the emulation analyzer 304 allows the existing exception handler in the kernel of the operating system 204 to handle the exception when the exception is a legacy exception (e.g., a legacy Alignment Check exception) .

When the emulation analyzer 304 determines that the exception is not to be injected back to a virtual machine or operating system, the emulation analyzer 304 notifies the instruction emulator 306 to emulate the instruction that triggered the exception.

The example instruction emulator 306 emulates locking instructions without the LOCK to enable the instruction to be performed without causing a bus lock that could interfere with the real-time workload 110 and/or the real-time application 210. The instruction emulator 306 handles the emulation based on the environment type (e.g., based on whether the environment is a virtual machine environment or a native environment) .

In the virtual environment (e.g., the computing system 100 illustrated in FIG. 1) , the instruction emulator 306 kicks other virtual CPUs associated with non-real-time workloads out of root mode (e.g., using an inter-processor interrupt (IPI) , a non-maskable interrupt (NMI) , or other operation to pause operation of the virtual CPUs) .

According to the illustrated example, if the instruction is an XCHG instruction with a memory operand (e.g., opcode 0x86 or 0x87) , the instruction emulator moves the memory operand into a temporary memory buffer, moves other register operand contents into the memory operand, moves the temporary memory buffer contents into the other register operand, and advances the RIP of the guest virtual machine (e.g., the second virtual machine 112) to skip the XCHG instruction.

Alternatively, if the instruction begins with a LOCK prefix, the instruction emulator 306 advances the RIP of the guest virtual machine by 1 byte (or any implementation specific distance to remove the LOCK prefix) . The instruction emulator 306 enables single step debugging (e.g., by setting RFLAGS. TF in the guest virtual machine) and enables the exception trap for the single step debugging exception (e.g., #DB) . Control is then returned to the guest virtual machine to continue execution (e.g., VM-Entry) . Alternatively, any other method for being alerted after the virtual machine executes its next instruction could be utilized by the instruction emulator 306 (e.g., a breakpoint (e.g., byte code 0xCC or INT3) could be set at the beginning of the next instruction, a monitor trap flag (MTF) could be set to trigger VM Exit) . Once the virtual machine executes the instruction, the exception (or breakpoint or other flag) is triggered (e.g., as RFLAGS. TF=1) and the exception is trapped by the exception manager 302. The example instruction emulator 306 then disables the single step debugging and exception trapping (or disables whatever other operations were previously enabled to catch the next instruction) . The instruction emulator 306 then resumes any paused virtual CPUs and the computer system 100 resumes normal operation and execution of workloads.

In the native environment (e.g., the computing system 200 illustrated in FIG. 2) , the instruction emulator 306 kicks other non-real-time CPU cores associated with non-real-time applications out of user space (e.g., using an inter-processor interrupt (IPI) , a non-maskable interrupt (NMI) , or other operation to pause operation of the CPU cores) .

According to the illustrated example, if the instruction is an XCHG instruction with a memory operand (e.g., opcode 0x86 or 0x87) , the instruction emulator moves the memory operand into a temporary memory buffer, moves other register operand contents into the memory operand, moves the temporary memory buffer contents into the other register operand, and advances the RIP of the application to skip the XCHG instruction.

Alternatively, if the instruction begins with a LOCK prefix, the instruction emulator 306 advances the RIP of the application by 1 byte (or any implementation specific distance to remove the LOCK prefix) . The instruction emulator 306 saves the next instruction (after the locking instruction) first byte (or other implementation specific prefix length) into a temporary buffer) . The instruction emulator 306 replaces the next instruction first byte in RIP with an interrupt instruction (e.g., 0xF1 -INT1) . The instruction emulator 306 switches context back to the user space for the non-real-time application 214, which executes the instruction without the LOCK prefix and the INT1 will trigger a debugger exception (e.g., #DB) . When the exception manager 302 alerts the instruction emulator 306 of the exception, the example instruction emulator 306 moves the RIP of the application by 1 byte (or implementation specific distance) and restores the element stored in the temporary buffer to the memory identified by the RIP. The instruction emulator 306 resumes any paused CPU cores and switches context back to the user space to resume execution of the computing system 200.

While an example manner of implementing the lock mitigation handler 116 of FIG. 1 and/or FIG. 2 is illustrated in FIG. 3, one or more of the elements, processes and/or devices illustrated in FIG. 3 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example exception manager 302, the example emulator analyzer 304, the example instruction emulator 306, and/or, more generally, the example lock mitigation handler 116 of FIG. 3 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example exception manager 302, the example emulator analyzer 304, the example instruction emulator 306, and/or, more generally, the example lock mitigation handler 116 of FIG. 3 could be implemented by one or more analog or digital circuit (s) , logic circuits, programmable processor (s) , programmable controller (s) , graphics processing unit (s) (GPU (s) ) , digital signal processor (s) (DSP (s) ) , application specific integrated circuit (s) (ASIC (s) ) , programmable logic device (s) (PLD (s) ) and/or field programmable logic device (s) (FPLD (s) ) . When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example exception manager 302, the example emulator analyzer 304, and/or the example instruction emulator 306 is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD) , a compact disk (CD) , a Blu-ray disk, etc. including the software and/or firmware. Further still, the example lock mitigation handler 116 of FIG. 1 and/or FIG. 2 may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in FIG. 3, and/or may include more than one of any or all of the illustrated elements, processes and devices. As used herein, the phrase “in communication, ” including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events.

Flowcharts representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the lock mitigation handler 116 of FIGS. 1, 2, and/or 3 are shown in FIGS. 4-6. The machine readable instructions may be one or more executable programs or portion (s) of an executable program for execution by a computer processor and/or processor circuitry, such as the processor 712 shown in the example processor platform 700 discussed below in connection with FIG. 7. The program may be embodied in software stored on a non-transitory computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor 712, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor 712 and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowcharts illustrated in FIGS. 4-6, many other methods of implementing the example lock mitigation handler 116 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp) , a logic circuit, etc. ) structured to perform the corresponding operation without executing software or firmware. The processor circuitry may be distributed in different network locations and/or local to one or more devices (e.g., a multi-core processor in a single machine, multiple processors distributed across a server rack, etc. ) .

The machine readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine readable instructions as described herein may be stored as data or a data structure (e.g., portions of instructions, code, representations of code, etc. ) that may be utilized to create, manufacture, and/or produce machine executable instructions. For example, the machine readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers) located at the same or different locations of a network or collection of networks (e.g., in the cloud, in edge devices, etc. ) . The machine readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc. in order to make them directly readable, interpretable, and/or executable by a computing device and/or other machine. For example, the machine readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and stored on separate computing devices, wherein the parts when decrypted, decompressed, and combined form a set of executable instructions that implement one or more functions that may together form a program such as that described herein.

In another example, the machine readable instructions may be stored in a state in which they may be read by processor circuitry, but require addition of a library (e.g., a dynamic link library (DLL) ) , a software development kit (SDK) , an application programming interface (API) , etc. in order to execute the instructions on a particular computing device or other device. In another example, the machine readable instructions may need to be configured (e.g., settings stored, data input, network addresses recorded, etc. ) before the machine readable instructions and/or the corresponding program (s) can be executed in whole or in part. Thus, machine readable media, as used herein, may include machine readable instructions and/or program (s) regardless of the particular format or state of the machine readable instructions and/or program (s) when stored or otherwise at rest or in transit.

The machine readable instructions described herein can be represented by any past, present, or future instruction language, scripting language, programming language, etc. For example, the machine readable instructions may be represented using any of the following languages: C, C++, Assembly, etc.

As mentioned above, the example processes of FIGS. 4-6 may be implemented using executable instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information) . As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

“Including” and “comprising” (and all forms and tenses thereof) are used herein to be open ended terms. Thus, whenever a claim employs any form of “include” or “comprise” (e.g., comprises, includes, comprising, including, having, etc. ) as a preamble or within a claim recitation of any kind, it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim or recitation. As used herein, when the phrase "at least" is used as the transition term in, for example, a preamble of a claim, it is open-ended in the same manner as the term "comprising" and “including” are open ended. The term “and/or” when used, for example, in a form such as A, B, and/or C refers to any combination or subset of A, B, C such as (1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) B with C, and (7) A with B and with C. As used herein in the context of describing structures, components, items, objects and/or things, the phrase "at least one of A and B" is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing structures, components, items, objects and/or things, the phrase "at least one of A or B" is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. As used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase "at least one of A and B" is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase "at least one of A or B" is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.

As used herein, singular references (e.g., “a” , “an” , “first” , “second” , etc. ) do not exclude a plurality. The term “a” or “an” entity, as used herein, refers to one or more of that entity. The terms “a” (or “an” ) , “one or more” , and “at least one” can be used interchangeably herein. Furthermore, although individually listed, a plurality of means, elements or method actions may be implemented by, e.g., a single unit or processor. Additionally, although individual features may be included in different examples or claims, these may possibly be combined, and the inclusion in different examples or claims does not imply that a combination of features is not feasible and/or advantageous.

The program 400 of FIG. 4 illustrates an example processing performed by the lock mitigation handler 116 operating in a virtual environment (e.g., operating within the hypervisor 104 in the example of FIG. 1) . The example process 400 begins when the exception manager 302 receives an indication of a locking instruction (block 402) . For example, the exception manager may detect an exception such as an #AC exception triggered by execution within the non-real-time workload 114 in the second virtual machine 112 of FIG. 1.

The emulation analyzer 304 determines if the exception is triggered by a locking instruction of interest (e.g., an instruction that will trigger a bus lock such as a split-lock instruction) (block 404) . According to the illustrated example, when the instruction is not an instruction of interest (e.g., one that is to be emulated) , the emulation analyzer 304 injects the instruction back to the virtual machine (block 406) and the process of FIG. 4 ends. If the instruction that triggered the exception is an instruction of interest, the emulation analyzer 304 determines if the virtual machine is set to handle such instructions (block 408) . If the virtual machine is set to handle such instructions/exceptions, control proceeds to block 406. Alternatively, the instruction emulator 306 determines if there are other virtual CPUs running non-real-time workloads (block 410) . When there are other virtual CPUs running, the instruction emulator 306 kicks the other virtual CPUs out of non-root mode to pause execution (block 412) .

After determining that there are no other virtual CPUs executing (block 410) or after pausing other virtual CPUs (block 412) , the example emulation analyzer 304 determines if the exception was triggered by an intrinsic lock instruction (e.g., an XCHG instruction) (block 414) . When the exception is associated with an intrinsic lock instruction, the instruction emulator 306 emulates the intrinsic lock instruction without triggering a split-lock or bus lock (block 416) and the process of FIG. 4 ends.

When the exception is not associated with an intrinsic lock (block 414) , the instruction emulator 306 advances a RIP of the second virtual machine 112 that triggered the exception by n byte (s) to remove the LOCK prefix, where n is the number of byte (s) associated with a LOCK prefix in the particular implementation (block 418) . The instruction emulator 306 then enables controlled debugging for the workload (e.g., the non-real-time workload 114) (block 420) . For example, the instruction emulator 306 may enable single step debugging, set a breakpoint after the next instruction, etc. The instruction emulator 306 further enables debugging exception trapping (e.g., trapping a #DB exception) (block 422) .

The instruction emulator 306 then allows the virtual machine to continue execution of the instruction (now without the LOCK prefix) (block 424) . Once the instruction is executed, the controlled debugging triggers an exception (e.g., the #DB exception) which is detected by the exception manager 302 (block 426) . The instruction emulator 306 disables the controlled debugging (428) and disables the debugging exception trapping (block 430) .

The instruction emulator 306 determines if there are other virtual CPUs in the virtual machine (block 432) . When there are other virtual CPUs running in the virtual machine, the instruction emulator 306 resumes the other virtual CPUs (e.g., returns them to non-root mode) (block 434) . When there are no other virtual CPUs or the virtual CPUs have been resumed, the instruction emulator 306 resumes execution of the virtual machine (block 436) . For example, the initial exception detected at block 402 will cause the virtual machine to pause execution of the virtual CPU thread that triggered the exception. The instruction emulator 306 may cause a VM-entry to resume the thread.

The program 500 of FIG. 5 illustrates an example processing performed by the lock mitigation handler 116 operating in a native environment (e.g., operating within the kernel of the operating system 204 in the example of FIG. 2) . The example process 500 begins when the exception manager 302 receives an indication of a locking instruction (block 502) . For example, the exception manager may detect an exception such as an #AC exception triggered by execution of the non-real-time application 214 of FIG. 1.

The emulation analyzer 304 determines if the exception is triggered by a locking instruction of interest (e.g., an instruction that will trigger a bus lock such as a split-lock instruction) (block 504) . According to the illustrated example, when the instruction is not an instruction of interest (e.g., one that is to be emulated) , the emulation analyzer 304 causes the exception to be handled by a legacy exception handler (e.g., a legacy exception handler of the operating system 204) (block 506) and the process of FIG. 5 ends. If the instruction that triggered the exception is an instruction of interest, the instruction emulator 306 determines if there are other CPU cores running non-real-time application (block 508) . When there are other CPU cores running, the instruction emulator 306 kicks the other virtual CPUs out of user space to pause execution (block 510) .

After determining that there are no other CPU cores executing (block 508) or after pausing other CPU cores (block 510) , the example emulation analyzer 304 determines if the exception was triggered by an intrinsic lock instruction (e.g., an XCHG instruction) (block 512) . When the exception is associated with an intrinsic lock instruction, the instruction emulator 306 emulates the intrinsic lock instruction without triggering a split-lock or bus lock (block 514) and the process of FIG. 5 ends.

When the exception is not associated with an intrinsic lock (block 512) , the instruction emulator 306 emulates the instruction that triggered the exception by removing the lock and execution the instruction (block 516) . An example process for emulating the instruction without the LOCK is described in conjunction with IFG. 6.

The instruction emulator 306 determines if there are other non-real-time CPU cores that were paused (block 518) . When there are other CPU cores, the instruction emulator 306 resumes the other CPU cores (e.g., returns them to user mode) (block 520) . When there are no other CPU cores or the CPU cores have been resumed, the instruction emulator 306 resumes execution by the computer system 200 (block 522) . For example, the initial exception detected at block 502 will cause the computer system 200 to pause execution of the CPU thread that triggered the exception. The instruction emulator 306 may resume the thread.

The program 600 of FIG. 6 illustrates an example processing performed by the lock mitigation handler 116 to emulate a locking instruction without performing the LOCK operation. For example, the process 600 may be utilized to implement block 516 of FIG. 5. Alternatively, the process 600 may be utilized to emulate a locking instruction in other implementations. The example process 600 begins with the instruction emulator 306 advancing a RIP associated with the application (e.g., the non-real-time application 210) that triggered the exception by n byte (s) to remove the LOCK prefix, where n is the number of byte (s) associated with a LOCK prefix in the particular implementation (block 602) . The instruction emulator 306 then saves the n byte (s) of the next instruction (e.g., the instruction following the locking instruction that triggered the exception) in a temporary buffer (block 604) . The instruction emulator 306 replaces n byte (s) of the next instruction in the RIP with an instruction that will trigger an interrupt (e.g., the instruction 0xF1 or INT1) (block 606) .

Now that the application execution is configured, the instruction emulator 306 triggers a context switch back to user space (out of the exception-triggered debugging) for the non-real-time process (e.g., the non-real-time application 214) to allow the non-real-time process to execute the instruction without the LOCK prefix (block 608) . Consequently, the non-real-time process executes the instruction at the RIP and the next instruction (e.g., the instruction to trigger the interrupt) . The exception handler 302 detects the exception triggered by the interrupt instruction (block 610) .

To restore the state to execute the original next instruction after the locking instruction, the instruction emulator 306 reverses the RIP by n byte (s) (block 612) . Then, the instruction emulator 306 restores the first n byte (s) of the next instruction from the temporary buffer (block 614) . The instruction emulator 306 then triggers a context switch back to user space to allow the non-real-time process to pick up execution at the original next instruction that was after the locking instruction (block 616) . The process of FIG. 6 then ends.

FIG. 7 is a block diagram of an example processor platform 700 structured to execute the instructions of FIGS. 4-6 to implement the lock mitigation handler 116 of FIGS. 1, 2, and/or 3. The processor platform 700 can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network) , a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad ^TM) , a personal digital assistant (PDA) , an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, a headset or other wearable device, or any other type of computing device.

The processor platform 700 of the illustrated example includes a processor 712. The processor 712 of the illustrated example is hardware. For example, the processor 712 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. In this example, the processor implements the example exception handler 302, the example emulation analyzer 304, and the example instruction emulator 306.

The processor 712 of the illustrated example includes a local memory 713 (e.g., a cache) . The processor 712 of the illustrated example is in communication with a main memory including a volatile memory 714 and a non-volatile memory 716 via a bus 718. The volatile memory 714 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM) , Dynamic Random Access Memory (DRAM) ,

Dynamic Random Access Memory

and/or any other type of random access memory device. The non-volatile memory 716 may be implemented by flash memory and/or any other desired type of memory device. Access to the

main memory

714, 716 is controlled by a memory controller.

The processor platform 700 of the illustrated example also includes an interface circuit 720. The interface circuit 720 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB) , a

interface, a near field communication (NFC) interface, and/or a PCI express interface.

In the illustrated example, one or more input devices 722 are connected to the interface circuit 720. The input device (s) 722 permit (s) a user to enter data and/or commands into the processor 712. The input device (s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video) , a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices 724 are also connected to the interface circuit 720 of the illustrated example. The output devices 724 can be implemented, for example, by display devices (e.g., a light emitting diode (LED) , an organic light emitting diode (OLED) , a liquid crystal display (LCD) , a cathode ray tube display (CRT) , an in-place switching (IPS) display, a touchscreen, etc. ) , a tactile output device, a printer and/or speaker. The interface circuit 720 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip and/or a graphics driver processor.

The interface circuit 720 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and/or a network interface to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 726. The communication can be via, for example, an Ethernet connection, a digital subscriber line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-site wireless system, a cellular telephone system, etc.

The processor platform 700 of the illustrated example also includes one or more mass storage devices 728 for storing software and/or data. Examples of such mass storage devices 728 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, redundant array of independent disks (RAID) systems, and digital versatile disk (DVD) drives.

The machine executable instructions 732 of FIGS. 4-6 may be stored in the mass storage device 728, in the volatile memory 714, in the non- volatile memory 716, and/or on a removable non-transitory computer readable storage medium such as a CD or DVD.

A block diagram illustrating an example software distribution platform 805 to distribute software such as the example computer readable instructions 732 of FIG. 7 to third parties is illustrated in FIG. 8. The example software distribution platform 805 may be implemented by any computer server, data facility, cloud service, etc., capable of storing and transmitting software to other computing devices. The third parties may be customers of the entity owning and/or operating the software distribution platform. For example, the entity that owns and/or operates the software distribution platform may be a developer, a seller, and/or a licensor of software such as the example computer readable instructions 732 of FIG. 7. The third parties may be consumers, users, retailers, OEMs, etc., who purchase and/or license the software for use and/or re-sale and/or sub-licensing. In the illustrated example, the software distribution platform 805 includes one or more servers and one or more storage devices. The storage devices store the computer readable instructions 732, which may correspond to the example computer readable instructions of FIGS. 4-6, as described above. The one or more servers of the example software distribution platform 805 are in communication with a network 810, which may correspond to any one or more of the Internet and/or any other network. In some examples, the one or more servers are responsive to requests to transmit the software to a requesting party as part of a commercial transaction. Payment for the delivery, sale and/or license of the software may be handled by the one or more servers of the software distribution platform and/or via a third-party payment entity. The servers enable purchasers and/or licensors to download the computer readable instructions 732 from the software distribution platform 805. For example, the software, which may correspond to the example computer readable instructions of FIG. 3-6, may be downloaded to the example processor platform 700, which is to execute the computer readable instructions 732 to implement the lock mitigation handler 116. In some example, one or more servers of the software distribution platform 805 periodically offer, transmit, and/or force updates to the software (e.g., the example computer readable instructions 732 of FIG. 7) to ensure improvements, patches, updates, etc. are distributed and applied to the software at the end user devices.

While the instructions 732 are shown in both the software distribution platform 805 and the processor platform (s) 700 in the illustrated example, the instructions 732 may be in different forms in both locations. For example, the instructions 732 stores in the software distribution platform 805 may be compressed, while the instructions 732 at the processor platform (s) may be decompressed (e.g., in a form set for execution) .

Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.

Example methods, apparatus, systems, and articles of manufacture to mitigate locks in real-time computing environments are disclosed herein. Further examples and combinations thereof include the following:

Example 1 includes a non-transitory computer readable medium comprising instructions that, when executed, cause a machine to at least detect an indication of an instruction that will trigger a bus lock within a computing system, cause processing in the computing system to be paused, emulate the instruction without the bus lock, and resume the processing in the computing system.

Example 2 includes a non-transitory computer readable medium as defined in example 1, wherein detecting the indication includes detecting an exception thrown by the computing system prior to the instruction executing.

Example 3 includes a non-transitory computer readable medium as defined in example 1, wherein the instruction is associated with a workload executing on a first virtual central processing unit of a first virtual machine and causing the processing to be paused includes causing execution by a second virtual central processing unit to be stopped.

Example 4 includes a non-transitory computer readable medium as defined in example 3, wherein the workload is a non-real-time workload and the computing system includes a second virtual machine executing a real-time workload.

Example 5 includes a non-transitory computer readable medium as defined in example 1, wherein the instruction is associated with a first software application executing on a first central processing unit core and causing the processing to be paused includes causing execution by a second central processing unit core be stopped.

Example 6 includes a non-transitory computer readable medium as defined in example 5, wherein the first software application is a non-real-time application and the computing system includes a real-time application executing on the computing system.

Example 7 includes a non-transitory computer readable medium as defined in example 1, wherein emulating the instruction without the bus lock includes advancing an instruction pointer of a processing unit past a LOCK prefix of the instruction.

Example 8 includes a non-transitory computer readable medium as defined in example 7, wherein emulating the instruction without the bus lock further includes enabling controlled debugging, executing the instruction after the LOCK prefix, and disabling controlled debugging.

Example 9 includes a non-transitory computer readable medium as defined in example 1, wherein the instruction is a first instruction and emulating the instruction without the bus lock includes storing a portion of a second instruction, the second instruction to be executed after the first instruction, replacing the portion of the second instruction with an instruction to trigger an interrupt, in response to detecting the interrupt after the first instruction executes, returning the stored portion of the second instruction to the second instruction, and setting an instruction pointer to begin a next execution at the start of the second instruction.

Example 10 includes an apparatus comprising an exception manager to detect an indication of an instruction that will trigger a bus lock within a computing system, an instruction emulator to cause processing in the computing system to be paused, emulate the instruction without the bus lock, and resume the processing in the computing system.

Example 11 includes an apparatus as defined in example 10, wherein the exception manager is to detect the indication by detecting an exception thrown by the computing system prior to the instruction executing.

Example 12 includes an apparatus as defined in example 10, wherein the instruction is associated with a workload executing on a first virtual central processing unit of a first virtual machine and the instruction emulator is to cause the processing to be paused by causing execution by a second virtual central processing unit to be stopped.

Example 13 includes an apparatus as defined in example 12, wherein the workload is a non-real-time workload and the computing system includes a second virtual machine executing a real-time workload.

Example 14 includes an apparatus as defined in example 10, wherein the instruction is associated with a first software application executing on a first central processing unit core and the instruction emulator is to cause the processing to be paused by causing execution by a second central processing unit core be stopped.

Example 15 includes an apparatus as defined in example 14, wherein the first software application is a non-real-time application and the computing system includes a real-time application executing on the computing system.

Example 16 includes an apparatus as defined in example 10, wherein the instruction emulator is to emulate the instruction without the bus lock by advancing an instruction pointer of a processing unit past a LOCK prefix of the instruction.

Example 17 includes an apparatus as defined in example 16, wherein the instruction emulator is to emulate the instruction without the bus lock by enabling controlled debugging, executing the instruction after the LOCK prefix, and disabling controlled debugging.

Example 18 includes an apparatus as defined in example 10, wherein the instruction is a first instruction and the instruction emulator is to emulate the instruction without the bus lock by storing a portion of a second instruction, the second instruction to be executed after the first instruction, replacing the portion of the second instruction with an instruction to trigger an interrupt, in response to detecting the interrupt after the first instruction executes, returning the stored portion of the second instruction to the second instruction, and setting an instruction pointer to begin a next execution at the start of the second instruction.

Example 19 includes a method comprising detecting an indication of an instruction that will trigger a bus lock within a computing system, causing processing in the computing system to be paused, emulating the instruction without the bus lock, and resuming the processing in the computing system.

Example 20 includes a method as defined in example 19, wherein detecting the indication includes detecting an exception thrown by the computing system prior to the instruction executing.

Example 21 includes a method as defined in example 19, wherein the instruction is associated with a workload executing on a first virtual central processing unit of a first virtual machine and causing the processing to be paused includes causing execution by a second virtual central processing unit to be stopped.

Example 22 includes a method as defined in example 21, wherein the workload is a non-real-time workload and the computing system includes a second virtual machine executing a real-time workload.

Example 23 includes a method as defined in example 19, wherein the instruction is associated with a first software application executing on a first central processing unit core and causing the processing to be paused includes causing execution by a second central processing unit core be stopped.

Example 24 includes a method as defined in example 23, wherein the first software application is a non-real-time application and the computing system includes a real-time application executing on the computing system.

Example 25 includes a method as defined in example 19, wherein emulating the instruction without the bus lock includes advancing an instruction pointer of a processing unit past a LOCK prefix of the instruction.

Example 26 includes a method as defined in example 25, wherein emulating the instruction without the bus lock further includes enabling controlled debugging, executing the instruction after the LOCK prefix, and disabling controlled debugging.

Example 27 includes a method as defined in example 19, wherein the instruction is a first instruction and emulating the instruction without the bus lock includes storing a portion of a second instruction, the second instruction to be executed after the first instruction, replacing the portion of the second instruction with an instruction to trigger an interrupt, in response to detecting the interrupt after the first instruction executes, returning the stored portion of the second instruction to the second instruction, and setting an instruction pointer to begin a next execution at the start of the second instruction.

The following claims are hereby incorporated into this Detailed Description by this reference, with each claim standing on its own as a separate embodiment of the present disclosure.

Claims

A non-transitory computer readable medium comprising instructions that, when executed, cause a machine to at least:

detect an indication of an instruction that will trigger a bus lock within a computing system;

cause processing in the computing system to be paused;

emulate the instruction without the bus lock; and

resume the processing in the computing system.
A non-transitory computer readable medium as defined in claim 1, wherein detecting the indication includes detecting an exception thrown by the computing system prior to the instruction executing.
A non-transitory computer readable medium as defined in claim 1, wherein the instruction is associated with a workload executing on a first virtual central processing unit of a first virtual machine and causing the processing to be paused includes causing execution by a second virtual central processing unit to be stopped.
A non-transitory computer readable medium as defined in claim 3, wherein the workload is a non-real-time workload and the computing system includes a second virtual machine executing a real-time workload.
A non-transitory computer readable medium as defined in claim 1, wherein the instruction is associated with a first software application executing on a first central processing unit core and causing the processing to be paused includes causing execution by a second central processing unit core be stopped.
A non-transitory computer readable medium as defined in claim 5, wherein the first software application is a non-real-time application and the computing system includes a real-time application executing on the computing system.
A non-transitory computer readable medium as defined in claim 1, wherein emulating the instruction without the bus lock includes advancing an instruction pointer of a processing unit past a LOCK prefix of the instruction.
A non-transitory computer readable medium as defined in claim 7, wherein emulating the instruction without the bus lock further includes enabling controlled debugging, executing the instruction after the LOCK prefix, and disabling controlled debugging.
A non-transitory computer readable medium as defined in claim 1, wherein the instruction is a first instruction and emulating the instruction without the bus lock includes:

storing a portion of a second instruction, the second instruction to be executed after the first instruction;

replacing the portion of the second instruction with an instruction to trigger an interrupt;

in response to detecting the interrupt after the first instruction executes, returning the stored portion of the second instruction to the second instruction; and

setting an instruction pointer to begin a next execution at the start of the second instruction.
An apparatus comprising:

an exception manager to detect an indication of an instruction that will trigger a bus lock within a computing system;

an instruction emulator to:

cause processing in the computing system to be paused;

emulate the instruction without the bus lock; and

resume the processing in the computing system.
An apparatus as defined in claim 10, wherein the exception manager is to detect the indication by detecting an exception thrown by the computing system prior to the instruction executing.
An apparatus as defined in claim 10, wherein the instruction is associated with a workload executing on a first virtual central processing unit of a first virtual machine and the instruction emulator is to cause the processing to be paused by causing execution by a second virtual central processing unit to be stopped.
An apparatus as defined in claim 12, wherein the workload is a non-real-time workload and the computing system includes a second virtual machine executing a real-time workload.
An apparatus as defined in claim 10, wherein the instruction is associated with a first software application executing on a first central processing unit core and the instruction emulator is to cause the processing to be paused by causing execution by a second central processing unit core be stopped.
An apparatus as defined in claim 14, wherein the first software application is a non-real-time application and the computing system includes a real-time application executing on the computing system.
An apparatus as defined in claim 10, wherein the instruction emulator is to emulate the instruction without the bus lock by advancing an instruction pointer of a processing unit past a LOCK prefix of the instruction.
An apparatus as defined in claim 16, wherein the instruction emulator is to emulate the instruction without the bus lock by enabling controlled debugging, executing the instruction after the LOCK prefix, and disabling controlled debugging.
An apparatus as defined in claim 10, wherein the instruction is a first instruction and the instruction emulator is to emulate the instruction without the bus lock by:

storing a portion of a second instruction, the second instruction to be executed after the first instruction;

replacing the portion of the second instruction with an instruction to trigger an interrupt;

in response to detecting the interrupt after the first instruction executes, returning the stored portion of the second instruction to the second instruction; and

setting an instruction pointer to begin a next execution at the start of the second instruction.
A method comprising:

detecting an indication of an instruction that will trigger a bus lock within a computing system;

causing processing in the computing system to be paused;

emulating the instruction without the bus lock; and

resuming the processing in the computing system.
A method as defined in claim 19, wherein detecting the indication includes detecting an exception thrown by the computing system prior to the instruction executing.
A method as defined in claim 19, wherein the instruction is associated with a workload executing on a first virtual central processing unit of a first virtual machine and causing the processing to be paused includes causing execution by a second virtual central processing unit to be stopped.
A method as defined in claim 21, wherein the workload is a non-real-time workload and the computing system includes a second virtual machine executing a real-time workload.
A method as defined in claim 19, wherein the instruction is associated with a first software application executing on a first central processing unit core and causing the processing to be paused includes causing execution by a second central processing unit core be stopped.
A method as defined in claim 23, wherein the first software application is a non-real-time application and the computing system includes a real-time application executing on the computing system.
A method as defined in claim 19, wherein emulating the instruction without the bus lock includes advancing an instruction pointer of a processing unit past a LOCK prefix of the instruction.
A method as defined in claim 25, wherein emulating the instruction without the bus lock further includes enabling controlled debugging, executing the instruction after the LOCK prefix, and disabling controlled debugging.
A method as defined in claim 19, wherein the instruction is a first instruction and emulating the instruction without the bus lock includes:

storing a portion of a second instruction, the second instruction to be executed after the first instruction;

replacing the portion of the second instruction with an instruction to trigger an interrupt;

in response to detecting the interrupt after the first instruction executes, returning the stored portion of the second instruction to the second instruction; and

setting an instruction pointer to begin a next execution at the start of the second instruction.