Methods and apparatus to enable code-based bus performance analysis

Methods and apparatus to enable code-based bus performance analysis are disclosed. In one example, a method identifies a bus transaction request with a virtual machine monitor and stores a record associated with the bus transaction request in a virtual machine.

TECHNICAL FIELD

The present disclosure is directed generally to computer systems and, more particularly, to methods and apparatus to enable code-based bus performance analysis.

BACKGROUND

Bus performance analysis such as transaction turn-around times and performance tuning provide useful mechanisms for debugging device drivers that initiate transactions with hardware devices via a bus. Current bus performance analysis techniques require the use of a hardware bus analyzer inserted into the bus under analysis.

Hardware bus analyzers have many shortcomings, such as cost, compatibility, scalability, and capability. For example, the cost of a typical hardware bus analyzer may exceed many thousands of dollars. When analyzing a peripheral component interconnect (PCI) bus, an industry standard architecture (ISA) hardware bus analyzer is not compatible with the PCI bus and therefore a PCI hardware bus analyzer is required. The hardware bus analyzer solution has poor scalability because it requires a one-to-one relationship between the hardware to be analyzed (i.e., the bus) and the number of hardware bus analyzers required. For example, to test a software or firmware device driver that initiates more than one transaction with more than one bus requires more than one hardware bus analyzer. Additionally, the capability of hardware bus analyzers is also a drawback. For example, the trace capability of a typical hardware bus analyzer is limited in size and functionality by the hardware bus analyzer, which typically has only one megabyte of trace capability.

DETAILED DESCRIPTION

In general, the methods and apparatus disclosed herein may be used to enable code-based bus performance analysis by capturing bus transaction activity via software and/or firmware. More specifically, some or all of the functionality of a hardware bus analyzer may be performed by software and/or firmware in a more cost-efficient, flexible, scalable, and productive fashion.

FIG. 1is a functional block diagram of an example code execution system100configured to enable code-based bus performance analysis. The code execution system100includes a bus102that is serially imposed between a processor104and peripheral hardware106.

The bus102and the processor104may be similar or identical to the bus614and the processor602, respectively, discussed in further detail below in conjunction withFIG. 6. The peripheral hardware106is hardware that is not part of the elementary computer system and may be implemented as a disk controller and mass storage (e.g., the disk controller and mass storage620ofFIG. 6), an adapter card (e.g., the adapter card630ofFIG. 6), an input device (e.g., the input device616ofFIG. 6), a network adapter (e.g., the network adapter636ofFIG. 6), a removable storage device drive (e.g., the removable storage device drive624ofFIG. 6), etc.

The processor104may include one or more of any type of well-known processor, such as a processor from the Intel® family of microprocessors having virtualization hardware, which allows for virtualization of hardware for a computer system, which may be implemented by a virtual machine monitor (VMM)108having a first application programming interface (API)110and a second API112that are communicatively coupled to a virtual machine (VM)114and a VM116via a plurality of communication links118,120,122, and124.

The VMM108may be a firmware or a software component that is configured to enable and support a series of virtual environments or VMs (e.g., the VM114and the VM116). The VMM108ensures that the operation of each of the plurality of VMs does not interrupt the operation of any other VM. In particular, the VMM108takes control of the code execution system100when one of the plurality of VMs attempts to perform an operation that may affect other VMs and/or the processor104.

The API110and the API112(i.e., a plurality of APIs) serve as a well-defined or published interface between the VMM108and the VM114and the VM116that make up a plurality of VMs. The plurality of VMs operates like a complete physical machine that can run instances of different and/or the same operating system (OS). For example, a first VM may include an OS such as the Microsoft® Windows® XP OS, a second VM may include an OS such as the Microsoft® Windows® 95 OS, and a third VM may include an OS such as the Linux OS. Typically, a crash of an OS in one of the plurality of VMs may not affect an OS executing in a different VM because the VMs have isolated resources. For example, the Microsoft® Windows® XP OS in the first VM and the Linux OS in the third VM may not be affected by a crash in the Microsoft® Windows® 95 OS in the second VM. The OS126may be any of the above mentioned OSs, such as a Microsoft® Windows® OS, UNIX® OS, Linux OS, etc.

The VM114includes an OS126having a plurality of applications and services128and a plurality of device drivers130that include a code library132. The VM116includes a transaction profiler134that is communicatively coupled to the bus102via a write communication link136and a read communication link138. Similarly, the VMM108is communicatively coupled to the bus102via a communication link140.

The applications and services128may include any application or service running on the OS126. For example, the applications and services128may include programs such as Microsoft® Word™, IBM®, Lotus Notes®, etc. that include instructions compiled, interpreted, or assembled from source code written in a computer programming language such as C/C++, Java, .NET, practical extraction and reporting language (Perl), assembly language, or any other suitable programming language.

The device drivers130may be software or firmware programs that enable the use of a device (e.g., the devices616,620,630,640, and624ofFIG. 6). For example, the device drivers130may include instructions compiled or assembled from source code written in a computer programming language such as C/C++, assembly language, or any other suitable programming language.

The code library132may be software or firmware that enables the device drivers130to communicate with the VMM108. For example, the code library132may include a function, a macro, etc. capable of generating the communication link118and a function, macro, call-back function, etc. capable of receiving data through the communication link122. While the device drivers130are shown as using the code library132to communicate with the VMM108, one of ordinary skill in the art will readily appreciate that communication between the device drivers130and the VMM108may be accomplished without the use of the code library132. For example, instructions embedded directly in the code of the device drivers130may enable communication with the VMM108.

The transaction profiler134may be one or more software or firmware programs that are capable of communicating directly with the bus102. For example, the transaction profiler134may be an application, a service, a device driver, etc. that executes with or without the assistance of an OS. The transaction profiler134reads and writes to one or more buses and stores logging information associated with the bus activity.

FIG. 2is a flow diagram of an example process for enabling code-based bus performance analysis200. The process200may be implemented by firmware or software on a processor, such as the processor104ofFIG. 1. While the following describes actions taken by the processor104in the implementation ofFIG. 2, it will be readily understood that the process200is not limited to execution on the example processor104and such a description is for purposes of clarity. The processor104begins execution of the process200by initializing the system (block202). The initialization of the system (block202) may include initializing the memory (e.g., the RAM606ofFIG. 6, etc.), initial loading of a plurality of drivers, and preparing to boot the system, etc. The processor104tests whether hardware such as memory, peripherals, and/or disk drives are functioning properly prior to booting the VMM108and one or more VMs (e.g., the VM114and the VM116). For example, the processor104may check whether a keyboard and/or a mouse are connected to the code execution system100. In another example, the processor104may check whether a disk (e.g., the removable storage media626ofFIG. 6) is inserted into a disk drive (e.g., the removable storage device drive624ofFIG. 6).

After initialization of the system (block202), the processor104launches the VMM108and one or more VMs (e.g., the VM114and VM116) (block204). The VMM108, which is executing in the processor104, virtualizes and boots up the VMs to partition the resources of the code execution system100. Each of the plurality of the VMs operates as if the all resources of the code execution system100are at the disposal of the VM and the VMM108coordinates the usage of the resources.

After launching the VMM108and one or more VMs (block204), the processor104determines if a start trap command has been requested from a requester (e.g., the code library132of the VM114) (block206). The processor104may implement the start trap command as a function, a macro, an inline instruction, an interrupt based instruction, a flag based instruction, or any other programming construct. For example, the start trap command may be implemented as a start trap function including a port address parameter that specifies a port address or a range of port addresses to be used as criteria for trapping. The start trap function may be part of the API110of the VMM108. When invoked by the requester (e.g., the code library132of the VM114or any other suitable requester), the start trap function may generate the communication link118and information about the requester (e.g., a callback function, an identifier of the VM, etc.). The information about the requester, which may be used for communicating with the requester, may be stored by the VMM108. If the start trap command has not been requested from the requester (e.g., the code library132of the VM114) (block206), the processor104performs system operations (block208). The system operations may perform normal OS operations until a function call, an interrupt based instruction, a flag based instruction, etc. is invoked, causing the processor104to determine if the start trap command has been requested from the requester (e.g., the VM114) (block206).

On the other hand, if the start trap command has been requested from the requester (e.g., the code library132of the VM114) (block206), the processor104generates a time stamp (e.g., a time stamp A1) (block210). The time stamp may be generated by the transaction profiler134, the VMM108, etc. and is representative of a time (e.g., a current time) at which an event occurs in a program. For example, the time stamp may be generated by the processor104based on a hardware timer. In particular, the time stamp may be generated by calling a function defined by an API specified by a programming language. For example, calling the C language function time ( ) returns the current time as a time stamp.

After generating the time stamp (block210), the processor104invokes an analyze performance process (block212). The analyze performance process performs code-based bus performance analysis on the bus102. The analyze performance process is described below in greater detail in conjunction withFIG. 3.

After returning from execution of the analyze performance process (block212), the processor104generates a time stamp (e.g., a time stamp A2) (block214) and then returns control to block208. The time stamp A2may be generated by the transaction profiler134, the VMM108, etc. and may implement a method similar or identical to the time stamp generation method described above in conjunction with block210.

FIG. 3is a flow diagram of an example analyze performance process300for analyzing performance of a bus, such as the bus102ofFIG. 1. As withFIG. 2, the process300ofFIG. 3is described in relation to components ofFIG. 1. In particular, the process300is described as being implemented in the VMM108that executes on the processor104. The analyze performance process300includes registered transaction checking, trapped transaction profiling, and bus extraction methods. The VMM108begins execution of the analyze performance process300by activating a trap on a registered transaction (block302). A trap is an executable instruction or set of instructions used to monitor one or more port addresses. A registered transaction is a transaction that has been requested to be transmitted on a monitored port address (i.e., a registered transaction is a transaction having a corresponding trap). According to one example, the VMM108may activate the trap by storing the port address to be monitored in a memory location as a trap variable. While, for example purposes, the registered transaction is discussed as being a single registered transaction, the registered transaction may be implemented as a plurality of registered transactions. For example, the trap variable may be implemented as an array of variables, a queue of variables, a stack of variables, a list of variables, or any other suitable data structure and the receipt of a registered transaction may insert a new value into the trap variable data structure.

After activating the trap on the registered transaction (block302), the VMM108determines if a stop trap command has been requested from a requester (e.g., the code library132of the VM114) (block304). The VMM108may implement the stop trap command as a function, a macro, an inline instruction, an interrupt based instruction, a flag based instruction, or any other programming construct. For example, the stop trap command may be implemented as a stop trap function including a port address parameter that specifies a port address or a range of port addresses no longer to be used as criteria for trapping. The stop trap function may be part of the API110of the VMM108and, when invoked by the requester (e.g., the code library132of the VM114or any other suitable requester), may generate the communication link118. If the stop trap command has been requested from the requester (e.g., the code library132of the VM114) (block304), the analyze performance process300ends and/or returns control to any calling routine(s) (block306).

On the other hand, if the stop trap command has not been requested from the requester (e.g., the code library132of the VM114) (block304), the analyze performance process300determines if the VMM108has trapped on the registered transaction from a requester (i.e., has received a transaction to be monitored) (block308). The received transaction is a transaction that is transmitted from the requester (e.g., the VM114) to the API110of the VMM108via the communication link118. The VMM108may compare the port address of the received transaction from the VM114to the trap variable for a match, and if a match occurs, the VMM108may determine that that the registered transaction has been trapped.

If the VMM108has trapped on a registered transaction (block308), the VMM108redirects or proxies the registered transaction to the transaction profiler134(block310) and invokes a profile trapped transaction process (block312). The registered transaction is redirected by the VMM108to the transaction profiler134via the communication link120(block310) to allow the transaction profiler134to process a trapped transaction (i.e., the received transaction from the VM114). Additionally or alternatively, the redirecting and invocation of the profile trapped transaction process may be implemented as a single activity. The profile trapped transaction process profiles and records information about the execution of the trapped transaction and is described below in greater detail in conjunction withFIG. 4.

After returning from execution of the profile trapped transaction process (block312), the VMM108transmits the received data (i.e., data that has been received on the bus102) to the requester (block313) and returns control to block304. The transmission of the received data may be implemented as a function call, a macro call, an inline instruction, an interrupt based instruction, a flag based instruction, or any other programming construct. The function that is called may be, for example, a call-back function in the code library132and/or the device drivers130of the VM114and the function call may generate the communication link122.

On the other hand, if the VMM108has not trapped on the registered transaction from the requester (block308), the VMM108determines if an extract transaction data command has been requested (block314). The extract transaction data command may be implemented as a function call, a macro, an inline instruction, an interrupt based instruction, a flag based instruction, or any other programming construct. For example, the extract transaction data command may be implemented as an extract transaction data function including a port address parameter that specifies a port address or a range of port addresses from which to extract the data. The extract transaction data function is invoked by a requester (e.g., the code library132) and information about the requester (e.g., a callback function, an identifier of the VM, etc.), which may be used for communicating with the requester, may be stored by the VMM108. The requester may be the same as or different from the requester. If the extract transaction data command has not been requested (block314), the VMM108returns control to block304.

On the other hand, if the extract transaction data command has been requested (block314), the VMM108transmits the received data to the requester (block316) and then returns control to block304. The received data may be requested by a requester (e.g., the requester) via the communication link118(block314), then the VMM108may request the data from the transaction profiler134via the communication link120, then the data may be transmitted from the transaction profiler134to the VMM108via the communication link124, and then further from the VMM108to the requester (e.g., the VM114) via the communication link122(block316).

FIG. 4is a flow diagram of an example profile trapped transaction process400that may be used to implement the profile trapped transaction process312ofFIG. 3. As withFIGS. 2 and 3, the process400ofFIG. 4is described in relation to components ofFIG. 1. The profile trapped transaction process400may be implemented in the transaction profiler134and profiles and records profiling results of bus transactions on the bus102. For example, the profiling results may be used by a human or a machine to determine a missing response to a write request to the bus102and/or to determine a latency time between when data is written to the bus102and when data is received as a response on the bus102. The transaction profiler134begins execution of the profile trapped transaction process400by receiving a trapped transaction from the VMM108(block402). For example, the trapped transaction may be received by the transaction profiler134via the communication link120.

After receiving a trapped transaction (block402), the transaction profiler134generates a time stamp (i.e., a time stamp B1) that is associated with a time before the processing of the trapped transaction (block404). The time stamp B1may be generated using a method similar or identical to the time stamp generation method described above in conjunction with block210ofFIG. 2.

After generating the time stamp B1(block404), the transaction profiler134inserts the trapped transaction onto the target bus (e.g., the bus102) (block406). The transaction profiler134may insert the trapped transaction onto the target bus (e.g., via the write communication link136) without transmitting the trapped transaction to the VMM108to avoid temporal latencies associated with the VMM108.

After inserting the trapped transaction onto the target bus (block406), the transaction profiler134receives data from the target bus (block408). For example, the transaction profiler134may wait until data on the target bus is received on the requested port address (e.g., via the read communication link138). Additionally, a timeout period may be implemented to stop waiting for the data if the data is not received.

After receiving the data on the target bus (block408), the transaction profiler134generates a time stamp (i.e., a time stamp B2) that is associated with a time after the processing of the trapped transaction (block410). The time stamp B2may be generated using a method similar or identical to the time stamp generation method described above in conjunction with block210ofFIG. 2.

After generating the time stamp B2(block410), the transaction profiler134stores a record of the trapped transaction (block412). The record is information associated with the trapped transaction and may include the port address, the time stamp B1, the time stamp B2, historical data, such as if data was returned on the target bus, etc. The record may be stored in one or more database files (e.g., a Microsoft Access database, an IBM DB2 database, database products from companies such as Oracle, Sybase, and Computer Associates, etc.), structures in memory (e.g., the system memory604ofFIG. 6), and/or any other suitable data storage mechanism or structure.

After storing a record of the trapped transaction (block412), the transaction profiler134transmits the received data to the VMM108(block414) and the process400ends and/or returns control to any calling routine(s) (block416). For example, the received data may be transmitted via the communication link124to the API112and, as discussed in further detail above in conjunction with block316ofFIG. 3, the API112may transmit the received data to the requester (e.g., the VM114) via the communication link122.

FIG. 5is a timing diagram500of an example execution of the example process ofFIG. 2. The timing diagram500includes a start trap time stamp502, a before transaction time stamp504, an after transaction time stamp506, and a stop trap time stamp508shown in a temporal relation where the left-most time stamp (i.e., the start trap time stamp502) is generated prior to the right-most time stamp (i.e., the stop time stamp508).

The start trap time stamp502is associated with the time at which a start trap has been received (e.g., the time stamp A1of block210ofFIG. 2). The stop trap time stamp508is associated with the time at which a stop trap has been received (e.g., the time stamp A2of block240ofFIG. 2). The start trap time stamp502and the stop trap time stamp508may be used to calculate the amount of time that occurs in executing one or more instructions. For example, the example pseudo code below shows a function definition called exampleFunction including a start trap function call (i.e., startTrap) and a stop trap function call (i.e., stopTrap) with a device driver that is being tested (i.e., deviceDriver) sequentially interposed between the two function calls.

Upon invocation of exampleFunction, the startTrap function is invoked, which results in the generation of the start trap time stamp502. After invocation of the startTrap function, the deviceDriver function is invoked. The deviceDriver function may issue, for example, a write request to the port address being monitored (i.e., the value of the portAddress variable). The transaction profiler134receives the write request from the VMM108and indirectly from the VM114as described above in conjunction with block402ofFIG. 4. The transaction profiler134generates the time stamp B1(i.e., the before transaction time stamp504) as described above in conjunction with block404ofFIG. 4and generates the time stamp B2(i.e., the after transaction time stamp506) as described above in conjunction with block410ofFIG. 4.

Upon completion of the deviceDriver function, the stopTrap function is invoked, which results in the generation of the stop trap time stamp508. The start trap time stamp502and the stop trap time stamp508may be used by a human or a machine to calculate the duration of the execution time of the deviceDriver function. The before transaction time stamp504and the after transaction time stamp506may also be used by a human or a machine to calculate the duration of a first transaction on the bus102. Additional before and after transaction time stamps may be processed in a similar manner to the before transaction time stamp504and the after transaction time stamp506and may be used for calculation of the duration of additional transactions requested by the deviceDriver function.

FIG. 6illustrates an example processor system600on which the disclosed processes may be executed. The system600includes a processor602having associated system memory604, which may be implemented using, for example, random access memory (RAM)606, read only memory (ROM)608, and/or flash memory610. The processor602is coupled to an interface, such as a bus614, to which other components may be coupled. In the illustrated example, the components interfaced to the bus614include an input device616, a mass storage device620, and a removable storage device drive624that may include associated removable storage media626, such as magnetic or optical media. The example processor system600may also include an adapter card630operatively coupled to a display device632and a network adapter636such as, for example, an Ethernet card or any other card that may be wired or wireless.

The example processor system600may be implemented using, for example, a server, a conventional desktop personal computer, a notebook computer, a workstation, or any other computing device. The processor602may be any type of processing unit, and may be similar or identical to the processor104ofFIG. 1.

The memories606,608, and610, which form some or all of the system memory604, may be any suitable memory devices and may be sized to fit the storage demands of the example processor system600. The RAM606may be implemented using a dynamic random access memory (DRAM), a static random access memory (SRAM), or any other suitable memory device. The flash memory610is a low-cost, high-density, high-speed architecture having low power consumption and high reliability. The flash memory610is a non-volatile memory that is accessed and erased on a block-by-block basis.

The input device616may be implemented using a keyboard, a mouse, a touch screen, a track pad, or any other device that enables a user to provide information to the processor602. The mass storage device620may be, for example, a conventional hard drive or any other magnetic or optical media that is readable by the processor602. For example, the mass storage device620may be a hard drive having storage capacity on the order of hundreds of megabytes to tens or hundreds of gigabytes.

The removable storage device drive624may be, for example, an optical drive, such as a CD-R drive, a CD-RW drive, a DVD drive, or any other optical drive. It may alternatively be, for example, a magnetic or solid state media drive. The removable storage media626is complementary to the removable storage device drive624, inasmuch as the media626is selected to operate with the removable storage device drive624. For example, if the removable storage device drive624is an optical drive, the removable storage media626may be a CD-R disk, a CD-RW disk, a DVD disk, or any other suitable optical disk. On the other hand, if the removable storage device drive624is a magnetic media device, the removable storage media626may be, for example, a diskette or any other suitable magnetic storage media.

The adapter card630may be any standard, commercially available adapter card that is used to interface the processor602to the display device632. The display device632may be, for example, a liquid crystal display (LCD) monitor, a cathode ray tube (CRT) monitor, or any other suitable device that acts as an interface between the processor602and a user via the adapter card630. The adapter card630is any device used to interface the display device632to the bus614. Such cards are presently commercially available from, for example, Creative Labs and other like vendors.

The network adapter636provides network connectivity between the processor602and a network638, which may be a local area network (LAN), a wide area network (WAN), the Internet, public switched telephone network (PSTN), or any other suitable network. The network638may include one or more network nodes, such as a network node640.

The network node640may be implemented using a server, a personal computer (PC), a personal digital assistant (PDA), an Internet appliance, a cellular telephone, or any other computing device. In an alternative example processor system, the processor602may be operatively coupled to the network node640without the assistance of the network638, such as via a serial adapter, a parallel adapter, the network adapter636operatively coupled to a cross-over Ethernet cable, etc.

As shown inFIGS. 2,3, and4, the processes200,300, and400may be implemented using one or more software programs or sets of machine readable instructions that are stored on a machine readable medium (e.g., the system memory604and/or the mass storage device620ofFIG. 6) and executed by one or more processors (e.g., the processor104ofFIG. 1). However, some or all of the blocks of the processes200,300, and400may be performed manually and/or by some other device. Additionally, although the processes200,300, and400are described with reference to the flow diagram illustrated inFIGS. 2,3, and4, persons of ordinary skill in the art will readily appreciate that many other methods of performing the processes200,300, and400may be used instead. For example, the order of many of the blocks may be altered, the operation of one or more blocks may be changed, blocks may be combined, and/or blocks may be eliminated.