WO2024086965A1

WO2024086965A1 - Testing device driver by combining the device driver, firmware emulation layer, embedded simulator, and model of hardware subsystem within single native host application

Info

Publication number: WO2024086965A1
Application number: PCT/CN2022/126953
Authority: WO
Inventors: Junjing SHI; Jakob ENGBLOM; Vincent Zimmer
Original assignee: Intel Corporation
Priority date: 2022-10-24
Filing date: 2022-10-24
Publication date: 2024-05-02

Abstract

Embodiments described herein are generally directed to testing of device drivers that interface with corresponding hardware subsystems. In an example, driver code (e.g., a UEFI device driver) for a hardware subsystem of a target system with which the driver code interacts may be tested by executing a single application compiled to natively run on a host processor. The application may include, among other things, the driver code and an embedded simulator that performs a simulation of the full dynamic behavior of the hardware subsystem based on a model of the hardware subsystem. As a given basic block of the driver code executes, a time of the simulation (e.g., a virtual cycle count of the model of the hardware subsystem) is advanced based on a number of instructions executed in the given basic block.

Description

TESTING A DEVICE DRIVER BY COMBINING THE DEVICE DRIVER, A FIRMWARE EMULATION LAYER, AN EMBEDDED SIMULATOR, AND A MODEL OF THE HARDWARE SUBSYSTEM WITHIN A SINGLE NATIVE HOST APPLICATION

TECHNICAL FIELD

Embodiments described herein generally relate to the field of testing of firmware or software device driver code and, more particularly, to testing and validation of Unified Extensible Firmware Interface (UEFI) firmware code that drives a certain hardware subsystem (e.g., a compute express link (CXL) device, a peripheral component interconnect express (PCIe) device, a point-to-point processor interconnect, storage device, or a system controller) by combining the device driver under test, an embedded simulator, and an existing model of the hardware subsystem within a single native host application, thereby enabling the use of host-based development tools to work with the device driver code.

BACKGROUND

When new hardware (e.g., processor, platform, System-on-Chip (SoC) , or system) is launched, software and firmware is required to be developed and/or updated to support the new hardware. This may include, among other things, basic boot code, UEFI, Basic Input-Output Systems (BIOS) , and device drivers.

Pre-silicon validation generally refers to testing performed on the new software and firmware before the availability of the hardware. Pre-silicon validation allows for earlier identification of bugs further upstream in the design and development process of such new software and firmware, reduces development times and enables more developers to access the latest simulated silicon. This “shift left” ultimately saves system integrators and other customers of hardware vendors both time in the product life cycle and money that would otherwise be invested in physical test platforms.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments described here are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

FIG. 1A is a block diagram illustrating a traditional hardware and virtual platform software stack.

FIG. 1B is a block diagram illustrating a single native host application that is able to reuse individual models of hardware subsystems and drivers from the standard hardware and virtual platform software stack according to some embodiments.

FIG. 2 is a flow diagram illustrating operations for running a model of a hardware subsystem with host-compiled software or firmware drivers according to some embodiments.

FIG. 3A is a block diagram illustrating basic blocks of an example code fragment and a corresponding control-flow graph.

FIG. 3B illustrates basic block instrumentation within assembly code corresponding to the example code fragment of FIG. 3A.

FIG. 4A is a block diagram illustrating inputs and outputs of a build and instrumentation process according to some embodiments.

FIG. 4B is a block diagram illustrating generation of a global system cycle to advance simulation virtual time from a host-compiled instrumented UEFI device driver according to some embodiments.

FIG. 5 is a flow diagram illustrating operations for performing basic block callback processing according to some embodiments.

FIG. 6 is an example of a computer system with which some embodiments may be utilized.

DETAILED DESCRIPTION

Embodiments described herein are generally directed to testing of device drivers that interface with corresponding hardware subsystems. In order to test UEFI firmware code that drives a certain hardware device before hardware is available, a model of the hardware is typically provided to interact with the firmware device driver code. The standard way to achieve pre-silicon testing is to build a virtual platform model of an entire platform as illustrated in FIG. 1A. FIG. 1A is a block diagram illustrating a traditional hardware and virtual platform software stack 100. In this example, a stand-alone platform is provided in the form of a simulator 134 running on a host computer to allow software developers an opportunity on which to run and test software, for example, before actual hardware 131 is available.

The simulator 134 represents a stand-alone virtual platform that models the actual hardware 131 and that can run the same software as the actual hardware 131. A non-limiting example of a simulator framework that may be utilized by the simulator 134 is the Intel Simics virtual platform. The simulator 134 includes an instruction-set simulator (ISS) 135 corresponding to each processor core 132 of the actual hardware 131 that mimics the behavior of the processor core 132 and provides a time reference for the simulation. For each subsystem 133 of the actual hardware, the simulator 134 also includes a corresponding model (model of subsystem 136) representing the full dynamic behavior of the subsystem 133, for example, with a time-based state machine. The subsystems 133 may include CXL devices, PCIe devices, point-to-point processor interconnects, storage devices, and/or system controllers.

The complete UEFI stack (e.g., the target full firmware stack 110) runs on the simulator 134, compiled in the same way as it would be for the actual hardware 131. The target full firmware stack includes UEFI device drivers 121a-n for respective subsystems 133 and a platform wrapper library 122. The platform wrapper library 122 provides access to the hardware to the UEFI device drivers 121a-n, for example, by including hardware interface code 125 that facilitates communication between the UEFI device drivers 121a-n and the platform (e.g., the actual hardware 131 or the simulator 134) on which it is running. A disadvantage of using the simulator 134 is software development tools (e.g., debuggers, profilers, code coverage analysis, etc. ) that may be used to interact with the UEFI device drivers 121a-n need to do so in a manner similar to working with a remote physical machine or a virtual machine because the UEFI device drivers 121a-n are not directly running on the host operating system but rather on top of a respective ISS 135, thereby limiting tool access.

Another common practice in industry is to use various forms of host-compiled setups to develop code for embedded systems and other architectures. In such setups, the software of interest is built to run on the host operating system (e.g., Linux, Windows, or macOS) and linked with an application programming interface (API) -level simulation of the target operating system or framework (e.g., UEFI or a real-time operating system (RTOS) ) . Such setups avoid the use of an ISS and make it possible to use host-based development tools to work with the target code, since the target code looks like a normal application running on the host operating system. For many programming tasks, the use of such a host-complied setup is more convenient than using the stand-alone virtual platform approach described above with reference to FIG. 1A. Additionally, a host-compilation framework currently exists for UEFI (e.g., the Edk2 EmulatorPkg) . There are simple hardware emulators used today in a host-compiled setting, but they do not provide a model of the full dynamic behavior of the hardware and instead rely on simple fixed values to simulate the registers of the hardware. A limitation of these solutions; however, is that they do not provide a model of the full dynamic behavior of the hardware and instead rely on simple fixed values to simulate the registers of the hardware.

Combining a host-compiled framework with existing virtual platform device models (e.g., models of subsystems 136) would produce a best-of-both-worlds operating environment. For example, such an environment would allow testing code (e.g., a UEFI device driver 121) in host-compiled mode against a given model of a subsystem 136 from the simulator 134, greatly expanding the power of the tests and potentially increasing the quality of the components prior to overall integration.

The following issues should generally be addressed to facilitate this type of simulation:

1. Instantiation of individual simulator models of subsystems (e.g., model of subsystem 136) inside the UEFI host-based simulation (e.g., single host application 140) .

2. Redirection of memory read and write operations from the UEFI device driver code (e.g., UEFI device drivers 121a-n) to the model of the subsystem (e.g., model of subsystem 136) . This issue is already handled by existing UEFI host-compiled frameworks (e.g., the Edk2 EmulatorPkg) .

3. Redirection of interrupts from the model of the subsystem to appropriate UEFI interrupt handers within the UEFI device driver code (e.g., UEFI device driver 121n) .

4. Mirroring memory contents written by firmware so that device models (e.g., UEFI device driver 121n) can do direct-memory access (DMA) when reading and writing descriptors in memory.

5. Advancing virtual time seen by the model of the subsystem (e.g., model of subsystem 136) as the UEFI device driver code (e.g., UEFI device driver 121n) executes on the host (to allow the simulation of time-dependent processes in the modeled hardware subsystem) .

This disclosure focuses primarily on issue numbers 1, 3, and 5 from above. Various embodiments described herein allow a model of a hardware subsystem to be run with host-compiled software of firmware drivers by directly combining existing models of subsystems developed for use in the context of a virtual platform with the host-compiled drivers, thereby avoiding the use of ISSs to run the code. As a result, the simulation is changed from a stand-alone virtual platform in which the target full firmware stack runs on ISSs as described above with reference to FIG. 1A to a single native host application that runs on the host operating system (e.g., Linux or Windows) as described further below with reference to FIG. 1B. According to one embodiment, driver code (e.g., a UEFI device driver) for a hardware subsystem of a target system with which the driver code interacts may be tested by executing a single application compiled to natively run on a host processor. The application includes, among other things, the driver code and an embedded simulator performing a simulation of dynamic behavior of the hardware subsystem based on an existing model of the hardware subsystem. The application may be compiled with profiling for time counting to make up for the exclusion of ISSs. For example, the instruction counters in the software workload binary may be instrumented to facilitate generation of an approximate execution time that drives the time-based state machine of the model of the hardware subsystem. In one embodiment, during a build process, a compiler code coverage feature instruments each basic block of the driver code with a callback function that reports the basic block identifier (ID) of the basic block. As a given basic block of the driver code executes, a time of the simulation (e.g., a virtual cycle count of the hardware model) is advanced based on a number of instructions executed in the given basic block. In this manner, host software development tools may be used to interact with the code under test as in the case of a traditional host-compiled setup.

In one embodiment, interrupts from the model of the subsystem are handled at the granularity of a basic block of the driver code, for example, during callbacks triggered by each basic block of the driver code.

In one embodiment, in addition to advancing the time of the simulation (e.g., the virtual cycle count of the model of the subsystem) , interrupts from the model of the subsystem since the last basic block may be redirected to appropriate interrupt handlers implemented by the driver code.

While for purposes of illustration various examples may be described with reference to pre-silicon validation/testing, it is to be appreciated the methodologies described herein are equally useful in connection with existing hardware for which it is desirable to develop drivers. As such, the life-cycle phase of the hardware is not intended to be limiting. Also, while various example, refer specifically to UEFI device drivers, the methodologies described herein may also be used for basic input/output system (BIOS) , Linux, or other device drivers.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be apparent, however, to one skilled in the art that embodiments described herein may be practiced without some of these specific details.

Terminology

The terms “connected” or “coupled” and related terms are used in an operational sense and are not necessarily limited to a direct connection or coupling. Thus, for example, two devices may be coupled directly, or via one or more intermediary media or devices. As another example, devices may be coupled in such a way that information can be passed there between, while not sharing any physical connection with one another. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate a variety of ways in which connection or coupling exists in accordance with the aforementioned definition.

If the specification states a component or feature “may” , “can” , “could” , or “might” be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.

As used in the description herein and throughout the claims that follow, the meaning of “a, ” “an, ” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.

As used herein, a “driver, ” “device driver, ” and the like generally refer to software or firmware that enables one or more hardware devices or subsystems to communicate with another device, subsystem, and/or a computer’s operating system and vice versa.

As used herein, a “basic block” generally refers to a sequence of code with one entry point and one exit point. Compilers usually decompose programs into their basic blocks as a first step in an analysis process. Basic blocks form the vertices or nodes in a control-flog graph, for example, as illustrated in FIG. 3A.

As used herein, a “callback” or “callback function” generally refers to a reference to executable code that is passed as an argument to another piece of code.

The terms “component” , “platform” , “system, ” “module, ” and the like as used herein are intended to refer to a computer-related entity, either a software-executing general purpose processor, hardware, firmware, or a combination thereof. For example, a component may be, but is not limited to being, a process running on a compute resource, an object, an executable, a thread of execution, a program, and/or a computer.

Example Operating Environment

FIG. 1B is a block diagram illustrating a single native host application that is able to reuse individual models of hardware subsystems and drivers from the standard hardware and virtual platform software stack according to some embodiments. Embodiments described herein generally relate to the field of testing of firmware or software device driver code and, more particularly, to testing and validation of UEFI firmware code that drives a certain hardware subsystem by combining, among other things, device driver code under test, a firmware emulation layer, an embedded simulator, and an existing model of a hardware subsystem driven by the device driver code under test within a single native host application, thereby enabling the use of host-based development tools to work with the device driver code.

In the context of the present example, a proposed execution and testing environment reuses individual models of subsystems (e.g., model of subsystem 136) and individual drivers (e.g., instrumented UEFI device driver 126) from a traditional virtual platform software stack (e.g., the virtual platform software stack 100 of FIG. 1A) , to enable IP-level (e.g., unit-level, subsystem-level) testing and validation running on a host processor (e.g., host processor core 137) in the form of a single host application (e.g., single host application 140) .

The single host application 140 is shown including target software or firmware code (e.g., instrumented UEFI device driver 126 for model of subsystem 136) intended to be run on hardware (e.g., the actual hardware 131) that may not currently be available, a platform wrapper library 123 for the host, an embedded simulator 138, and a time counter 139. The single host application 140 is compiled for native execution by a host operating system (not shown) on a host processor core 137, thereby facilitating usage of host software development tools 150 (e.g., debuggers, profilers, code coverage analysis, etc. ) . For example, Microsoft Visual Studio may be used to perform source-level debugging of the target software or firmware code.

As there is no ISS in the present example and the models of the subsystems 136 are event-driven and require an event queue that drives virtual time forward, the progress of virtual time should be kept synchronized with the target software or firmware code that is executing. For instance, virtual time should stand still when the software code is “paused” (e.g., after hitting a breakpoint or being single-stepped in an interactive debugger session) . In one embodiment, a particular UEFI device driver (e.g., UEFI device driver 121a-n) for a specific hardware system (e.g., subsystem 133) may be compiled with profiling add instrumentation to the particular UEFI device driver to create the instrumented UEFI device driver 126 as described further below with reference to FIG. 4A. The instrumentation within the instrumented UEFI device driver 126 may facilitate time counting by the time counter 139 as described further below with reference to FIGs. 4B and 6. For example, virtual time may be advanced by counting the number of host instructions executed by target software or firmware code, which represents a reasonable approximation that ensures that loops that wait for time-driven changes to the model of subsystem 136 will execute in a realistic manner. In one embodiment, the time for the model of subsystem 136 is handled by standard virtual platform clock devices.

Continuing with the present example, the platform wrapper library 123 may be analogous to platform wrapper library 122 with the exception of including different interface code (i.e., simulation interface code 124 instead of hardware interface code 125) . The platform wrapper library essentially replicates the behavior towards the device driver that platform wrapper library 122 would produce on the actual hardware, for example, by translating between the model of subsystem 136 so that the device driver code can be left as-is. In one embodiment, the simulation interface code 124 facilitates redirection of hardware accesses by the instrumented UEFI device driver 126 to the model of subsystem 136.

Turning now to the simulator 138, it may be generally analogous to the simulator framework (e.g., Simics) utilized by simulator 134 but for the fact that it is embedded within the single host application 140 as a result of being compiled-in. The simulator 138 is shown running a model of subsystem 136. The model of subsystem 136 may implement one or more time-based state machines to mimic the full dynamic behavior of a corresponding hardware subsystem (e.g., subsystem 133) of the actual hardware 131. Non-limiting examples of hardware subsystems that may be modeled by the model of subsystem 136 include a CXL device, a PCIe device, a point-to-point processor interconnect, a storage device, or a system controller.

Example Driver Code Testing/Validation

FIG. 2 is a flow diagram illustrating operations for running a model of a hardware subsystem with host-compiled software or firmware drivers according to some embodiments. In one embodiment, the host-compiled software or firmware driver may be compiled with profiling to instrument the resulting binary with a callback function for each basic block of the software or firmware driver as described further below with reference to FIGs. 3A-B and 4A to facilitate (i) advancement of virtual time of a simulation of a hardware subsystem (e.g., subsystem 133) based on a model thereof (e.g., model of subsystem 136) by a simulator (e.g., simulator 138) and/or (ii) handling of interrupts raised by the model at the granularity of a basic block.

At block 210, an application (e.g., single host application 140) that can be natively run on a host processor (e.g., host processor core 137) is built in which the application includes, among other things, (i) driver code under test (e.g., instrumented UEFI device driver 126) , for a hardware subsystem of a target system (e.g., actual hardware 131) with which the driver code interacts; and (ii) an embedded simulator (e.g., simulator 138) that performs a simulation of dynamic behavior of the hardware subsystem using a model of the hardware subsystem (e.g., model of subsystem 136) .

At block 220, the driver code may be tested and/or validated by executing the application on the host processor. According to one embodiment, the testing may involve the use of a host-based development tool (e.g., one of host software development tools 150) running concurrently on the host processor with the driver code and a platform wrapper (e.g., platform wrapper 123) . For example, Microsoft Visual Studio may be used to perform source-level debugging of the driver code.

At block 230, as each basic block of the driver code executes, the current simulation time (e.g., a virtual cycle count of model of the subsystem) is advanced based on a number of instructions executed in the basic block. In one embodiment, as described further below with reference to FIGs. 3A-B and 4A-B at build time, the number of instructions for each basic block of the driver code may be determined and each basic block may be assigned a unique identifier (ID) , which may be referred to herein as a basic block ID. In an alternative embodiment, processor counter monitoring may be leveraged to count the executed instructions on the fly. In the case of the former, a callback function inserted into each basic block of the driver code may report its respective basic block ID, which may be mapped to its corresponding instruction count. In the case of the latter, the callback functions may instead report a count of the executed instructions from the processor since the last report on the fly. In either case, the current simulation time may be advanced. For example, the instruction count may be converted to a cycle count and the cycle count may be used to drive the time of the embedded simulator forward, providing progress of time for the state machine of the model of the hardware subsystem.

Example Basic Block Instrumentation

FIG. 3A is a block diagram illustrating basic blocks of an example code fragment 310 and a corresponding control-flow graph 315. In the context of the present example, the example code fragment 310 illustrates the concept of basic blocks (BBs) with a simple function containing a conditional statement, representing a first BB (BB1) , when the conditional statement is true, control flows to a second BB (BB2) and when the conditional statement is false, control flows to a third BB (BB3) as illustrated by the control-flow graph 315.

FIG. 3B illustrates basic block instrumentation within assembly code corresponding to the example code fragment 310 of FIG. 3A. As illustrated by FIG. 3B, each BB (BB1, BB2, and BB3) represented by the example code fragment 310 corresponds to a sequence of assembly code having a single entry point and a single exit point. Assembly code sequence 320a corresponds to BB1, assembly code sequence 320b corresponds to BB2, and assembly code sequence 320c corresponds to BB3. In various examples described herein, at build time, each BB of a device driver (e.g., UEFI device driver 121n) is instrumented with a corresponding callback (or callback function) (e.g., callback 321a-c) to add hooks into the compiled code. In one embodiment, the hooks are added by compiling the device driver with profiling enabled.

According to one embodiment, as the compiler adds instrumentation to the BBs of the device driver, a unique BB ID may be assigned to each BB that may be calculated with reference to a BB start offset in the binary. Additionally, the number of instructions associated with each BB may be counted and associated with the corresponding BB ID within an instruction count table that may be used at run-time to determine the number of instructions executed by the BB. For example, as described below with reference to FIG. 6, in one embodiment, the callback triggers execution of a method exposed by a BB callback library to facilitate advancing of simulation virtual time and processing of interrupts raised by the model of the hardware subsystem at the granularity of a BB of the device driver.

Example Build and Instrumentation

FIG. 4A is a block diagram illustrating inputs and outputs of a build and instrumentation process according to some embodiments. In the context of the present example, a device driver (e.g., UEFI device driver 421) for a specific hardware subsystem (e.g., one of subsystems 133) , an emulator package 422 (e.g., a UEFI host-based simulation provided by a UEFI host-compiled framework, such as the Edk2 EmulatorPkg) , and a basic block (BB) callback library 423 are combined at build time by a build and instrumentation process 430 to produce a single host application 440 (which may be analogous to single host application 140) that includes, among other things, an instrumented UEFI device driver 426. The instrumented UEFI device driver 426 represents the UEFI device driver 421 with BB-level instrumentation (e.g., callbacks to a method exposed by the BB callback library 423 or otherwise hooked by the BB callback library 423) .

According to one embodiment, the build and instrumentation process 430 is performed by a compiler (e.g., the Clang compiler) with profiling enabled to instrument each BB of the UEFI device driver 421 with a callback. In general, any compiler that allows for user-defined hooks may be used. During the build and instrumentation process 430, each BB may be assigned a unique ID (the BB ID) . For example, a counter may be instrumented for each BB based on a BB start offset in the binary. Additionally, the number of instructions may be counted for each BB and the BB ID of each BB may be mapped to the corresponding the number of instructions of the BB by way of an instruction count table (e.g., the instruction count table 443 of FIG. 4B) . In this manner, in one embodiment, as callbacks are made during execution of the device driver, reporting their respective unique BB IDs, the number of instructions executed by a given BB may be retrieved from the instruction count table during the callback. The BB callback library 423 may represent a statically-linked library.

Example Advancement of Simulation Virtual Time

FIG. 4B is a block diagram illustrating generation of a global system cycle to advance simulation virtual time from a host-compiled instrumented UEFI device driver according to some embodiments. In the context of the present example, the single host application 440 is shown including the instrumented UEFI device driver 426, a BB callback 442, a simulator 448, the instruction count table 443, and an interrupt (INT) flag and handler table 444.

The simulator 448 performs a simulation of the full dynamic behavior of a specific hardware subsystem based on a model thereof (e.g., model of subsystem 436, which may be analogous to model of subsystem 136) . A time-based state machine of the model may be driven by a current simulation time of the simulator 448 as indicated by a cycle timer 445. When an interrupt is raised by the model of subsystem 436, a corresponding flag may be set within the interrupt flag and handler table 444. According to one embodiment, each potential interrupt that may be raised by the model of subsystem 436 includes an entry in the interrupt flag and handler table 444 that maps a given INT to a corresponding interrupt handler implemented by the instrumented UEFI device driver 426. In one embodiment, a platform wrapper library (e.g., platform wrapper library 123) may be involved in the initialization of the interrupt flag and handler table 444 based on interrupt handlers implemented by the device driver.

According to one embodiment, during execution of the single host application 440, as a given BB (the reporting BB) of the instrumented UEFI device driver 426 is executed, the BB callback is invoked with a parameter indicating the BB ID of the given BB. The BB callback 442 is shown performing an interrupt relay 441 and including an instruction count to cycle converter 439. The instruction count to cycle count converter is responsible for retrieving the number of instructions executed by the reporting BB from the instruction count table 443 based on the BB ID of the reporting BB, converting the instruction count to a corresponding cycle count, and driving the cycle timer 445 forward based on the conversion.

The code implementing the interrupt relay 441 may be part of a platform wrapper library (e.g., platform wrapper library 123) and scans the interrupt flag and handler table to determine whether any interrupts have been raised by the model of subsystem 436 and if so, invoking the corresponding interrupt handler of the instrumented UEFI device driver 426. Further description of processing that may be performed by the BB callback 442 is provided below with reference to FIG. 6. According to one embodiment, both (i) advancement of the current simulation time and (ii) checking for and processing of interrupts are performed during each invocation of the BB callback 442.

Example Basic Block Callback Processing

FIG. 5 is a flow diagram illustrating operations for performing basic block callback processing according to some embodiments. The processing described with reference to FIG. 5 may be performed within a single native host application (e.g., single host application 140) that combines device driver code (e.g., instrumented UEFI device driver 126) with an embedded simulator (e.g., simulator 138) that performs a simulation of the dynamic behavior of a given hardware subsystem (e.g., subsystem 133) based on a model of the given hardware subsystem (e.g., model of subsystem 136) . For example, the BB callback processing may be performed within a method (e.g., BB callback 442) exposed by or otherwise hooked by a BB callback library (e.g., BB callback library 423) , which may be linked to the single native host application during a build and instrumentation process as described above with reference to FIG. 4A.

At block 510, a notification is received from the device driver code that a BB of the device driver code has been executed. For example, a callback (e.g., one of callbacks 321a-c) added to the BB during the build and instrumentation process may be made to or hooked by the BB callback library at some point during the execution of the BB (e.g., at the end of the BB) . Depending upon the particular implementation, the callback may include the unique BB ID of the BB from which the callback was made and/or an indication regarding the number of instructions executed by the BB.

At block 520, during the callback virtual time seen by a model of the hardware subsystem (e.g., model of subsystem 136) is advanced. For example, as illustrated in FIGs. 4B, as each basic block of the driver code executes, the current simulation time (e.g., the virtual cycle count of the model of the hardware subsystem) may be advanced based on a number of instructions executed in the BB containing the callback. Depending upon the particular implementation, the number of instructions associated with a given BB may be pre-counted (at build time) and stored within an instruction count table (e.g., instruction count table 443) and looked up as the given BB is executed. Alternatively, a processor counter mechanism (e.g., the Intel processor counter monitor (PCM) ) may be leveraged to count the executed instructions on the fly. Regardless of the source of the instruction count, the instruction count may be converted to a cycle count and the cycle count may then be used to drive the time of the embedded simulator forward, providing progress of time for the state machine (s) of the model of the hardware subsystem.

At block 530, the interrupt flag of a first/next interrupt entry in an interrupt table (e.g., interrupt flag and handler table 444) is checked. By driving the time of the embedded simulator forward in block 520, the model of subsystem may raise one or more interrupts and flag them within the interrupt flag and handler table.

At decision block 540, it is determined whether the interrupt flag for the interrupt entry at issue is set (e.g., is true) . If so, processing continues with block 550; otherwise, processing branches to decision block 560.

At block 550, the interrupt handler is run. For example, an interrupt relay (e.g., interrupt relay 441) implemented within a platform wrapper library (e.g., platform wrapper library 123) may invoke an interrupt handler of the device driver code specified by the interrupt entry at issue.

At decision block 560, it is determined whether another interrupt entry remains to be checked. If so, processing loops back to block 530 to check the next interrupt entry in the interrupt table; otherwise, BB callback processing for the BB at issue is complete.

While in the context of the flow diagrams presented herein, a number of enumerated blocks are included, it is to be understood that the examples may include additional blocks before, after, and/or in between the enumerated blocks. Similarly, in some examples, one or more of the enumerated blocks may be omitted or performed in a different order.

Example Computer System

FIG. 6 is an example of a computer system 600 with which some embodiments may be utilized. Notably, components of computer system 600 described herein are meant only to exemplify various possibilities. In no way should example computer system 600 limit the scope of the present disclosure. In the context of the present example, computer system 600 includes a bus 602 or other communication mechanism for communicating information, and one or more processing resources 604 coupled with bus 602 for processing information. The processing resources may be, for example, a combination of one or more compute resources (e.g., a microcontroller, a microprocessor, a CPU, a CPU core, a GPU, a GPU core, an ASIC, an FPGA, or the like) or a system on a chip (SoC) integrated circuit. Referring back to FIG. 1B, the host system on which the single host application 140 runs may be analogous to computer system 600 and the host processor core 137 may be analogous to the one or more processing resources 604.

Computer system 600 also includes a main memory 606, such as a random-access memory (RAM) or other dynamic storage device, coupled to bus 602 for storing information and instructions to be executed by processor 604. Main memory 606 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 604. Such instructions, when stored in non-transitory storage media accessible to processor 604, render computer system 600 into a special-purpose machine that is customized to perform the operations specified in the instructions.

Computer system 600 further includes a read only memory (ROM) 608 or other static storage device coupled to bus 602 for storing static information and instructions for processor 604. A storage device 610, e.g., a magnetic disk, optical disk or flash disk (made of flash memory chips) , is provided and coupled to bus 602 for storing information and instructions.

Computer system 600 may be coupled via bus 602 to a display 612 for displaying information to a computer user. An input device 614, including alphanumeric and other keys, is coupled to bus 602 for communicating information and command selections to processor 604. Another type of user input device is cursor control 616, such as a mouse, a trackball, a trackpad, or cursor direction keys for communicating direction information and command selections to processor 604 and for controlling cursor movement on display 612. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y) , that allows the device to specify positions in a plane.

Removable storage media 640 can be any kind of external storage media, including, but not limited to, hard-drives, floppy drives,

Zip Drives, Compact Disc –Read Only Memory (CD-ROM) , Compact Disc –Re-Writable (CD-RW) , Digital Video Disk –Read Only Memory (DVD-ROM) , USB flash drives and the like.

Computer system 600 may implement the techniques described herein, for example, by running a single native host application (e.g., single host application 140) on processor 604, using customized hard-wired logic, one or more ASICs or FPGAs, firmware or program logic which in combination with the computer system causes or programs computer system 600 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 600 in response to processor 604 executing one or more sequences of one or more instructions contained in main memory 606. Such instructions may be read into main memory 606 from another storage medium, such as storage device 610. Execution of the sequences of instructions contained in main memory 606 causes processor 604 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

The term “storage media” as used herein refers to any non-transitory media that store data or instructions that cause a machine to operation in a specific fashion. Such storage media may comprise non-volatile media or volatile media. Non-volatile media includes, for example, optical, magnetic or flash disks, such as storage device 610. Volatile media includes dynamic memory, such as main memory 606. Common forms of storage media include, for example, a flexible disk, a hard disk, a solid-state drive, a magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.

Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 602. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 604 for execution. For example, the instructions may initially be carried on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 600 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 602. Bus 602 carries the data to main memory 606, from which processor 604 retrieves and executes the instructions. The instructions received by main memory 606 may optionally be stored on storage device 610 either before or after execution by processor 604.

Computer system 600 also includes interface circuitry 618 coupled to bus 602. The interface circuitry 618 may be implemented by hardware in accordance with any type of interface standard, such as an Ethernet interface, a universal serial bus (USB) interface, a

interface, a near field communication (NFC) interface, a PCI interface, and/or a PCIe interface. As such, interface 618 may couple the processing resource in communication with one or more discrete accelerators 605 (e.g., one or more XPUs) .

Interface 618 may also provide a two-way data communication coupling to a network link 620 that is connected to a local network 622. For example, interface 618 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, interface 618 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, interface 618 may send and receive electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link 620 typically provides data communication through one or more networks to other data devices. For example, network link 620 may provide a connection through local network 622 to a host computer 624 or to data equipment operated by an Internet Service Provider (ISP) 626. ISP 626 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the “Internet” 628. Local network 622 and Internet 628 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 620 and through communication interface 618, which carry the digital data to and from computer system 600, are example forms of transmission media.

Computer system 600 can send messages and receive data, including program code, through the network (s) , network link 620 and communication interface 618. In the Internet example, a server 630 might transmit a requested code for an application program through Internet 628, ISP 626, local network 622 and communication interface 618. The received code may be executed by processor 604 as it is received, or stored in storage device 610, or other non-volatile storage for later execution.

While many of the methods may be described herein in a basic form, it is to be noted that processes can be added to or deleted from any of the methods and information can be added or subtracted from any of the described messages without departing from the basic scope of the present embodiments. It will be apparent to those skilled in the art that many further modifications and adaptations can be made. The particular embodiments are not provided to limit the concept but to illustrate it. The scope of the embodiments is not to be determined by the specific examples provided above but only by the claims below.

If it is said that an element “A” is coupled to or with element “B,” element A may be directly coupled to element B or be indirectly coupled through, for example, element C. When the specification or claims state that a component, feature, structure, process, or characteristic A “causes” a component, feature, structure, process, or characteristic B, it means that “A” is at least a partial cause of “B” but that there may also be at least one other component, feature, structure, process, or characteristic that assists in causing “B. ” If the specification indicates that a component, feature, structure, process, or characteristic “may” , “might” , or “could” be included, that particular component, feature, structure, process, or characteristic is not required to be included. If the specification or claim refers to “a” or “an” element, this does not mean there is only one of the described elements.

An embodiment is an implementation or example. Reference in the specification to “an embodiment, ” “one embodiment, ” “some embodiments, ” or “other embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least some embodiments, but not necessarily all embodiments. The various appearances of “an embodiment, ” “one embodiment, ” or “some embodiments” are not necessarily all referring to the same embodiments. It should be appreciated that in the foregoing description of exemplary embodiments, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various novel aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed embodiments requires more features than are expressly recited in each claim. Rather, as the following claims reflect, novel aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims are hereby expressly incorporated into this description, with each claim standing on its own as a separate embodiment.

The following clauses and/or examples pertain to further embodiments or examples. Specifics in the examples may be used anywhere in one or more embodiments. The various features of the different embodiments or examples may be variously combined with some features included and others excluded to suit a variety of different applications. Examples may include subject matter such as a method, means for performing acts of the method, at least one machine-readable medium including instructions that, when performed by a machine cause the machine to perform acts of the method, or of an apparatus or system for facilitating hybrid communication according to embodiments and examples described herein.

Some embodiments pertain to Example 1 that includes a non-transitory machine-readable medium storing instructions, which when executed by a processing resource of a computer system cause the processing resource to: execute driver code for a hardware system of a target system by running an application compiled to natively execute on a host processor, wherein the application includes a simulation of dynamic behavior of the hardware system; and advance a time of the simulation based on a number of instructions executed.

Example 2 includes the subject matter of Example 1, wherein the native application further includes a basic block callback library and wherein during building of the driver code, the driver code is instrumented with a callback to the basic block callback library for each of a plurality of basic blocks.

Example 3 includes the subject matter of Example 2, wherein during the building of the driver code, the number of instructions is determined and stored within a data structure mapping a unique identifier (ID) of a given basic block of the plurality of basic blocks of the driver code to the number of instructions and wherein the method further comprises during the callback, looking up the number of instructions within the data structure based on the unique ID.

Example 4 includes the subject matter of Example 2, wherein the instructions further cause the processing resource to during the callback: determine whether an interrupt has been raised by the model; and after a given interrupt has been determined to have been raised, invoke a corresponding interrupt handler.

Example 5 includes the subject matter of any of Examples 1-4, wherein the driver code comprises Unified Extensible Firmware Interface (UEFI) firmware code.

Example 6 includes the subject matter of any of Examples 1-5, wherein the hardware subsystem comprises a compute express link (CXL) device, a peripheral component interconnect express (PCIe) device, a point-to-point processor interconnect, a storage device, or a system controller.

Example 7 includes the subject matter of any of Examples 1-6, wherein the native host application does not implement an instruction-set simulator.

Some embodiments pertain to Example 8 that includes a method comprising: testing driver code for a hardware system of a target system by executing an application compiled to natively run on a host processor, wherein the application includes a simulation of dynamic behavior of the hardware system based on a model of the hardware subsystem; and advancing a time of the simulation based on a number of instructions executed.

Example 9 includes the subject matter of Example 8, wherein the native application further includes a basic block callback library and wherein during building of the driver code, the driver code is instrumented with a callback to the basic block callback library for each of a plurality of basic blocks.

Example 10 includes the subject matter of Example 9, wherein during the building of the driver code, the number of instructions is determined and stored within a data structure mapping a unique identifier (ID) of a given basic block of the plurality of basic blocks of the driver code to the number of instructions and wherein the method further comprises during the callback, looking up the number of instructions within the data structure based on the unique ID.

Example 11 includes the subject matter of Example 9, further comprising during the callback: determining whether an interrupt has been raised by the model; and after a given interrupt has been determined to have been raised, running a corresponding interrupt handler.

Example 12 includes the subject matter of any of Examples 8-11, wherein the driver code comprises Unified Extensible Firmware Interface (UEFI) firmware code.

Example 13 includes the subject matter of any of Examples 8-12, wherein the hardware subsystem comprises a compute express link (CXL) device, a peripheral component interconnect express (PCIe) device, a point-to-point processor interconnect, a storage device, or a system controller.

Example 14 includes the subject matter of any of Examples 8-13, further comprising debugging the driver code using a host-based software development tool running on the host processor.

Example 15 includes the subject matter of any of Examples 8-14, wherein the native host application does not implement an instruction-set simulator.

Some embodiments pertain to Example 16 that includes a computer system comprising: a processing resource; and instructions, which when executed by the first processing resource cause the processing resource to: execute driver code for a hardware subsystem of a target system with which the driver code interacts by running an application compiled to natively execute on a host processor, wherein the application includes the driver code and a simulator performing a simulation of dynamic behavior of the hardware subsystem based on a model of the hardware subsystem; and as a given basic block of a plurality of basic blocks of the driver code executes, advance a time of the simulation for the model of the hardware subsystem based on a number of instructions executed in the given basic block.

Example 17 includes the subject matter of Example 16, wherein the native application further includes a basic block callback library and wherein during building of the driver code, the driver code is instrumented with a callback to the basic block callback library for each of the plurality of basic blocks.

Example 18 includes the subject matter of Example 17, wherein during the building of the driver code, the number of instructions is determined and stored within a data structure mapping a unique identifier (ID) of the given basic block to the number of instructions and wherein the method further comprises during the callback, looking up the number of instructions within the data structure based on the unique ID.

Example 19 includes the subject matter of Example 17, wherein the instructions further cause the processing resource to during the callback: determine whether an interrupt has been raised by the model; and after a given interrupt has been determined to have been raised, invoking a corresponding interrupt handler.

Example 20 includes the subject matter of any of Examples 16-19, wherein the driver code comprises Unified Extensible Firmware Interface (UEFI) firmware code.

Some embodiments pertain to Example 21 that includes an apparatus that implements or performs a method of any of Examples 8-15.

Example 22 includes at least one machine-readable medium comprising a plurality of instructions, when executed on a computing device, implement or perform a method or realize an apparatus as described in any preceding Example.

Example 23 includes an apparatus comprising means for performing a method as claimed in any of Examples 8-15.

The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

Claims

A non-transitory machine-readable medium storing instructions, which when executed by a processing resource of a computer system cause the processing resource to:

execute driver code for a hardware system of a target system by running an application compiled to natively execute on a host processor, wherein the application includes a simulation of dynamic behavior of the hardware system; and

advance a time of the simulation based on a number of instructions executed.
The non-transitory machine-readable medium of claim 1, wherein the native application further includes a basic block callback library and wherein during building of the driver code, the driver code is instrumented with a callback to the basic block callback library for each of a plurality of basic blocks.
The non-transitory machine-readable medium of claim 2, wherein during the building of the driver code, the number of instructions is determined and stored within a data structure mapping a unique identifier (ID) of a given basic block of the plurality of basic blocks of the driver code to the number of instructions and wherein the method further comprises during the callback, looking up the number of instructions within the data structure based on the unique ID.
The non-transitory machine-readable medium of claim 2, wherein the instructions further cause the processing resource to during the callback:

determine whether an interrupt has been raised by the model; and

after a given interrupt has been determined to have been raised, invoke a corresponding interrupt handler.
The non-transitory machine-readable medium of claim 1, wherein the driver code comprises Unified Extensible Firmware Interface (UEFI) firmware code.
The non-transitory machine-readable medium of claim 1, wherein the hardware subsystem comprises a compute express link (CXL) device, a peripheral component interconnect express (PCIe) device, a point-to-point processor interconnect, a storage device, or a system controller.
The non-transitory machine-readable medium of claim 1, wherein the native host application does not implement an instruction-set simulator.
A method comprising:

testing driver code for a hardware system of a target system by executing an application compiled to natively run on a host processor, wherein the application includes a simulation of dynamic behavior of the hardware system based on a model of the hardware subsystem; and

advancing a time of the simulation based on a number of instructions executed.
The method of claim 8, wherein the native application further includes a basic block callback library and wherein during building of the driver code, the driver code is instrumented with a callback to the basic block callback library for each of a plurality of basic blocks.
The method of claim 9, wherein during the building of the driver code, the number of instructions is determined and stored within a data structure mapping a unique identifier (ID) of a given basic block of the plurality of basic blocks of the driver code to the number of instructions and wherein the method further comprises during the callback, looking up the number of instructions within the data structure based on the unique ID.
The method of claim 9, further comprising during the callback:

determining whether an interrupt has been raised by the model; and

after a given interrupt has been determined to have been raised, running a corresponding interrupt handler.
The method of claim 8, wherein the driver code comprises Unified Extensible Firmware Interface (UEFI) firmware code.
The method of claim 8, wherein the hardware subsystem comprises a compute express link (CXL) device, a peripheral component interconnect express (PCIe) device, a point-to-point processor interconnect, a storage device, or a system controller.
The method of claim 8, further comprising debugging the driver code using a host-based software development tool running on the host processor.
The method of claim 8, wherein the native host application does not implement an instruction-set simulator.
A computer system comprising:

a processing resource; and

instructions, which when executed by the first processing resource cause the processing resource to:

execute driver code for a hardware subsystem of a target system with which the driver code interacts by running an application compiled to natively execute on a host processor, wherein the application includes the driver code and a simulator performing a simulation of dynamic behavior of the hardware subsystem based on a model of the hardware subsystem; and

as a given basic block of a plurality of basic blocks of the driver code executes, advance a time of the simulation for the model of the hardware subsystem based on a number of instructions executed in the given basic block.
The computer system of claim 16, wherein the native application further includes a basic block callback library and wherein during building of the driver code, the driver code is instrumented with a callback to the basic block callback library for each of the plurality of basic blocks.
The computer system of claim 17, wherein during the building of the driver code, the number of instructions is determined and stored within a data structure mapping a unique identifier (ID) of the given basic block to the number of instructions and wherein the method further comprises during the callback, looking up the number of instructions within the data structure based on the unique ID.
The computer system of claim 17, wherein the instructions further cause the processing resource to during the callback:

determine whether an interrupt has been raised by the model; and

after a given interrupt has been determined to have been raised, invoking a corresponding interrupt handler.
The computer system of claim 16, wherein the driver code comprises Unified Extensible Firmware Interface (UEFI) firmware code.