CN1842771A - Mechanisms for dynamic configuration of virtual processor resources - Google Patents

Abstract

The invention relates to a virtual multi-processor context, one or several virtual processing element context, and arrangement logic, wherein said virtual multi-processor context defines the resources and controls the arrangement of virtual multi-processor; said one virtual processing element context is relative to one of virtual processing element; the virtual processing element context has the first logic, to define if one virtual processing element is allowed to own these resources; and the second logic for defining the subgroup of the resource distributed to the virtual processing element; said arrangement logic is connected to the virtual multi-processor context and the virtual processing element context; the arrangement logic detects if one virtual processing element is allowed to arrange said resources, to refresh the virtual multi-processor context to make said virtual multi-processor into arrangement state, and distribute said resources via refreshing one defined virtual processing element.

Description

A Mechanism for Dynamically Allocation of Virtual Processor Resources

[Cross-references to related patent applications]

This patent application claims the benefit of the following US provisional patent applications, which are hereby incorporated by reference. serial number filing date title 60/499180 (MIPS.0188-00-US) 8/28/03 Special extensions for multi-threaded applications 60/502358 (MIPS.0188-02-US) 9/12/03 Application-specific extensions to multithreading for a processor architecture 60/502359 (MIPS.0188-03-US) 9/12/03 Application-specific extensions to multithreading for a processor architecture

This patent application is a continuation-in-part of the following commonly owned non-provisional United States patent applications, each of which has the same assignee and at least one common inventor, which are hereby incorporated by reference. serial number filing date title 10/684350 (MIPS.0188-01-US) 10/10/03 Mechanisms for ensuring quality of service for program execution on a multithreaded processor 10/684348 (MIPS.0189-00-US) 10/10/03 Integrated mechanism for suspending and deallocating computation thread execution in a processor

The above mentioned two co-owned non-provisional US patent applications claim the rights to the following US provisional patent applications. serial number filing date title 60/499180 (MIPS.0188-00-US) 8/28/03 Special extensions for multi-threaded applications 60/502358 (MIPS.0188-02-US) 9/12/03 Application-specific extensions to multithreading for a processor architecture 60/502359 (MIPS.0188-03-US) 9/12/03 Application-specific extensions to multithreading for a processor architecture

This patent application is related to the following co-owned non-provisional US patent applications, each of which is incorporated herein by reference. serial number filing date title (MIPS.0189-01-US) 8/27/04 Integrated mechanism for suspending and deallocating computation thread execution in a processor (MIPS.0192-00-US) 8/27/04 Apparatus, method, and instructions for simultaneous initiation of instruction streams in a multithreaded microprocessor (MIPS.0194-00-US) 8/27/04 Mechanism for software management of multiple computing contexts

【Technical field】

The present invention relates generally to the field of virtual multiprocessors, and more particularly, to a mechanism for dynamic allocation of resources within a virtual multiprocessor among one or more virtual processing elements.

【Background technique】

Today, designers employ many techniques to increase the performance of microprocessors. Most microprocessors operate with a clock signal that runs at a fixed frequency. In each clock cycle, the circuits of the microprocessor perform their corresponding functions. According to Hennessy and Patterson, the true measure of microprocessor performance is the time it takes to execute a program or a group of programs. From this point of view, the performance of a microprocessor is its clock frequency, the average number of clock cycles required to execute an instruction (in other words, the average number of instructions executed per clock cycle), and the A function of the number of instructions executed in the group program. Semiconductor scientists and engineers continue to provide advances in technology that allow microprocessors to operate at faster clock frequencies. These technological advances effectively shrink the size of transistors, resulting in faster switching times within an integrated circuit. The number of instructions executed depends primarily on the tasks to be performed by the program, although it is also affected by the microprocessor's instruction set architecture. However, substantial performance gains have been achieved by architectural and organizational techniques that increase the number of instructions executed per clock cycle, in particular by techniques that allow instructions to be executed in parallel (ie, parallel processing theory).

Parallel processing techniques that have increased the number of instructions per clock cycle of microprocessors, and their clock frequency, are pipelined. In a manner quite similar to the stages of an assembly line, within a microprocessor pipeline stage, the pipeline overlaps the execution of multiple instructions. In an ideal situation, an instruction moves down the pipeline every clock cycle to a new stage that performs a different function for those instructions. Thus, although each individual instruction takes several clock cycles to complete, the average clock time per instruction is reduced because the clock cycles of the individual instructions overlap. The performance improvement of the pipeline is realized when the instructions in the program are allowed, that is, the execution of an instruction does not need to depend on its previous instruction, so it can be executed in parallel with its previous instruction, which is usually called instruction-level parallel processing. Another method of instruction-level parallel processing adopted by today's microprocessors is to issue many executed instructions to different functional units in the same clock cycle, and each unit performs its specified function. Microprocessors that achieve instruction-level parallel processing in this way are often referred to as "superscalar" microprocessors.

The parallel processing mechanisms discussed above are related to the respective instruction-level parallel processing. However, the performance improvements achieved through the development of instruction-level parallel processing are limited. The various limitations imposed by limited instruction-level parallel processing and other performance-limiting issues have recently reinvigorated the exploitation of the instruction block level, or the instruction sequence level, or the instruction stream level, or the instruction thread (thread) Hierarchical, parallel processing of interest. Parallel processing at this level usually refers to thread-level parallel processing. A thread is a sequence or stream of program instructions. A multithreaded microprocessor executes many threads simultaneously according to some scheduling principle that governs the fetching and dispatching of instructions for the various threads, such as interleaving, blocking, or simultaneous multithreading. In a concurrent fashion, a multithreaded microprocessor typically allows many threads to share the microprocessor's functional units (e.g., instruction fetch and decode units, caches, branch prediction units, and load and store, integer, floating point, SIMD, etc. execution units). However, a multi-threaded microprocessor contains multiple sets of hardware/firmware resources, or thread contexts, which are used to store the unique state of each thread to enable the ability to quickly switch between threads to fetch and dispatch instructions . For example, each thread context contains its own program counter for instruction fetches and thread identification information, and typically also contains its own set of general-purpose registers.

An example of a performance limiting problem caused by a multi-threaded microprocessor is the fact that memory misses must be accessed outside the microprocessor, usually with a relatively long latency. The memory access time in today's microprocessor-based computer systems is typically between 1 and 2 orders of magnitude greater than the cache hit access time. As a result, some or all of the pipeline stages of a single-threaded microprocessor may idle for many clock cycles without performing any useful work while the pipeline stalls waiting for data from memory. Multi-threaded microprocessors can alleviate this situation by issuing instructions from other threads during memory fetch latencies, thus allowing pipeline stages to advance to perform useful work, somewhat like an operating system responds to page faults. Perform task switching but at a more precise level of granularity. Another example of a performance-limiting problem is pipeline stalls and their accompanying clock idling, due to incorrect branch predictions and accompanying pipeline flushes, either due to data dependencies, or due to a long-latency instruction such as a divide instruction. Furthermore, the ability of a multithreaded microprocessor to dispatch instructions from other threads to idle pipeline stages can greatly reduce the time required to execute the programs or groups of programs that make up those threads. Another problem, especially in embedded systems, is the wasteful overhead associated with servicing interrupts. Typically, when an I/O device sends an interrupt signal to the microprocessor, the microprocessor switches control to an interrupt service routine that requests to store the current program state and service the interrupt. When the interrupt is serviced Reply to the current program status. A multi-threaded microprocessor provides the ability for the event service code to become its own thread, which has its own thread context. Thus, in response to the I/O device signaling an event, the microprocessor can switch to the event service thread very quickly, perhaps within one clock cycle, thereby avoiding the overhead of conventional interrupt service routines.

Just as the degree of instruction-level parallelism indicates the extent to which a microprocessor can take advantage of the benefits of pipelining and superscalar instruction issuance, the degree of thread-level parallelism indicates the extent to which a microprocessor can take advantage of the benefits of multithreaded execution. An important feature of a thread is that it is completely independent of other threads being executed on a multithreaded microprocessor. A thread is independent of other threads to the extent that its instructions do not depend on instructions on other threads. The thread-independent feature allows the microprocessor to execute instructions from different threads simultaneously. That is, the microprocessor can issue instructions from one thread to the execution units without concern for instructions issued by other threads. Provided that threads access common data, the threads themselves must be programmed to mutually synchronize data access to ensure proper operation, so that the microprocessor instruction issue phase need not be concerned with dependencies.

From the aforementioned observations, it can be concluded that a processor with a multi-threaded context, executing many threads simultaneously, can reduce the time required to execute a program or a group of programs including these threads. However, the introduction of multithreaded contexts also introduces a new set of problems, especially for system software, to manage multiple instruction streams and their associated thread contexts. The present inventors have shown that another level of parallel processing is required to increase the parallel processing associated with instruction execution in a microprocessor. In this and related applications, the inventors have addressed the provision of virtual processing elements within the same microprocessor. Applied to this level, a multi-threaded virtual processing element, in addition to implementing a number of program counters and thread contexts to ensure efficient switching of program threads, implements all the resources required to provide a given instruction set and privileged resource architecture. A single instantiation, the architecture is sufficient to execute a per-processor OS image. In effect, a microprocessor implementing N virtual processing elements (that is, a virtual microprocessor with N virtual processing elements) presents to operating system software an N-way symmetric multiprocessor . The practical difference between a virtual multiprocessor according to the present invention and a conventional symmetric multiprocessor is that, in addition to shared memory and some degree of connectivity, the virtual processing elements in a virtual multiprocessor also share virtual On-chip resources or attributes of a microprocessor, such as instruction fetch and issue logic, address translation logic (i.e., translation lookaside buffer logic), functional units, such as integer unit, symbol unit, multimedia unit, media acceleration unit, SIMD units, and coprocessors. In addition, the virtual processing elements must share the performance attributes or utilization aspects (i.e., bandwidth) of the virtual multiprocessor, which are determined by the number of threads allocated to each virtual processing element, when execution is required, with a Threads associated with a virtual processing element may have a higher degree of priority than threads associated with other virtual processing elements, and are given certain processor-wide resources (e.g., load and store buffers) for that virtual processing element Configuration. For example, consider an embedded system in which two different processes occur simultaneously: real-time compression of audiovisual data and operation of a user graphical interface. Using late 20th century technology, these tasks can be accomplished by using two different processors: a real-time digital signal processor to process multimedia data and an interactive processor core to execute a multitasking operating system. The invention allows these two functions to be executed on the same virtual multiprocessor. Two virtual processing elements of the virtual multiprocessor will be employed: one dedicated to multimedia processing tasks and the other dedicated to user interface tasks. Using two virtual processing elements solves the co-existence or co-exemplification problem of two different software examples, but does not guarantee the same real-time performance requirements as a dedicated processor, because the multimedia virtual processing element and the user Interface virtual processing elements must share certain resources within virtual multiprocessors and the performance of applications executing on a virtual multiprocessor, as mentioned above, is based on how those resources or attributes are issued to each virtual Processing elements.

In a market where multiprocessing applications present a broad and varied resource requirement, it would be costly to manufacture virtual multiprocessors with resources tailored to a particular multiprocessing application. Accordingly, the inventors have observed that it would be desirable to provide a virtual multiprocessor that can be used across a wide range of multiprocessing applications. He further stated that it is highly desirable that the virtual multiprocessor includes a mechanism for resource allocation of various virtual processing elements through software. Such mechanisms should allow the virtual multiprocessor to be configured with one or more virtual processing elements, where each virtual processing element is configured to execute one or more threads. Furthermore, at runtime, it would be desirable to have these resources dynamically configured by trusted virtual processing elements and to provide a mechanism to revoke configuration privileges.

【Content of invention】

The present invention is directed to solving the above mentioned problems as well as addressing other problems, disadvantages, and limitations of the prior art. The present invention proposes an excellent mechanism for dynamically configuring the resources of a virtual multiprocessor. In one embodiment, a means is provided for configuring resources of one or more virtual processing elements in a virtual multiprocessor. The apparatus includes a virtual multiprocessor context, one or more virtual processing element contexts, and configuration logic. The virtual multiprocessor context specifies these resources and controls the configuration state of the virtual multiprocessor. The one or more virtual processing element contexts each uniquely correspond to one or more virtual processing elements. Each of the one or more virtual processing element contexts has first logic for specifying whether one of the one or more virtual processing element contexts is allowed to configure the resources; and second logic for specifying the resources assigned to the one or more A subset of resources of the one of the plurality of virtual processing elements. The configuration logic is connected to a virtual multiprocessor context, and to one or more virtual processing element contexts. The configuration logic detects whether one of the one or more virtual processing elements is allowed to configure these resources, updates the virtual multiprocessor context to indicate that the virtual multiprocessor enters the configured state, and configures these resources by updating a specified virtual processing element context resource.

One aspect of the present invention provides a resource allocation mechanism for assigning resources to virtual processing elements in a virtual multiprocessor. The resource allocation mechanism has virtual multiprocessor registers, virtual processing element registers for each virtual processing element, and configuration logic. The virtual multiprocessor registers specify these resources and control the configuration state of the virtual multiprocessor. The virtual processing element register specifies whether a corresponding virtual processing element is allowed to assign the resources, and specifies a subset of the resources that are assigned to the corresponding virtual processing element. The configuration logic is coupled to the virtual multiprocessor registers and the virtual processing element registers. The configuration logic detects whether the corresponding virtual processing element is allowed to assign the resources, updates the virtual multiprocessor registers to indicate that the virtual multiprocessor has entered a configured state, and assigns the resources by updating selected ones of the virtual processing element registers.

Another aspect of the invention provides a computer program product for use with a computing device. The computer program product includes a computer-usable medium including computer-readable program code embodied in the medium, configured to describe an apparatus for allocating resources to virtual processing elements in a virtual multiprocessor. The computer readable program code has a first program code, a second program code, and a third program code. The first program code describes a virtual multiprocessor context. The virtual multiprocessor context specifies these resources and controls the configuration state of the virtual multiprocessor. The second program code describes virtual processing element contexts, each of which is individually mapped to a virtual processing element and specifies whether the one virtual processing element is allowed to allocate the resources and specifies which resources are assigned to the one virtual processing element A subset of resources. The third program code describes the configuration logic. The configuration logic is coupled to the virtual multiprocessor context and the virtual processing element context. The configuration logic detects whether one of the virtual processing elements is allowed to configure the resources, updates the virtual multiprocessor context to indicate that the virtual multiprocessor enters a configured state, and configures the resources by updating a specified virtual processing element context .

Another aspect of the present invention provides computer data signals embedded in a transmission medium. The computer data signals have computer readable program code configured to describe a means for allocating resources to virtual processing elements in a virtual multiprocessor. The computer readable program code includes a first program code, a second program code, and a third program code. The first program code describes a virtual multiprocessor context, wherein the virtual multiprocessor context specifies the resources and controls the configuration state of the virtual multiprocessor. The second program code describes virtual processing element contexts, each virtual processing element context is individually mapped to a virtual processing element, and specifies whether the virtual processing element is allowed to allocate these resources, and specifies to be assigned to the virtual processing element A subset of resources. The third program code describes configuration logic coupled to the virtual multiprocessor context and the virtual processing element context. The configuration logic detects whether the a virtual processing element is allowed to configure the resources, updates the virtual multiprocessor context to instruct the virtual multiprocessor to enter configuration state, and configures the resources by updating a specified virtual processing element context.

Yet another aspect of the present invention provides a method for allocating resources for virtual processing elements in a virtual multiprocessor. The method includes: via a virtual multiprocessor context, first specifying these resources, and controlling the configuration state of the virtual multiprocessor; via the virtual processing element context, each virtual processing element context is individually corresponding to one of the virtual processing elements, A second specifies whether a virtual processing element is allowed to configure the resources, and a third specifies the subset of resources assigned to a virtual processing element; and via configuration logic connected to the virtual multiprocessor context and the virtual processing element context , detects whether one of the virtual processing elements is allowed to configure these resources, and first updates the virtual multiprocessor context to indicate that the virtual multiprocessor enters the configuration state, and configures these resources by second updating a specified virtual processing element context .

Yet another aspect of the present invention provides a virtual multiprocessing system. The virtual multiprocessing system includes a memory and a plurality of virtual processors. The memory stores program instructions associated with a number of program threads. The virtual multiprocessor is connected to the memory. The virtual multiprocessor executes the program instructions on one or more virtual processing elements configured in the virtual multiprocessor. The virtual multiprocessor has a virtual multiprocessor context that specifies the configured resources of the one or more virtual processing elements and controls the configuration state of the virtual multiprocessor. Each of the one or more virtual processing elements includes a virtual processing element context and a configuration logic. The virtual processing element context specifies whether each of the one or more virtual processing elements is allowed to configure the resources, and specifies a subset of resources assigned to the specified one of the one or more virtual processing elements. The configuration logic is coupled to the virtual multiprocessor context and the virtual processing element context. The configuration logic detects whether each of the one or more virtual processing elements is allowed to configure these resources, updates the virtual multiprocessor context to indicate that the virtual multiprocessor enters the configured state, and updates the These resources are configured in the specified virtual processing element context of a specified one of the virtual processing elements.

【Description of drawings】

These and other objects, features and advantages of the present invention will be more readily understood from the following description and accompanying drawings.

Fig. 1 is a block diagram depicting a multiprocessing environment according to the present invention;

Fig. 2 is a block diagram depicting a virtual multiprocessor pipeline according to the present invention;

Figure 3 is a block diagram showing a dynamically configurable virtual multiplexer according to the present invention;

Figure 4 is a table representing virtual multiprocessing context registers consistent with an exemplary embodiment of the present invention;

Figure 5 is a series of block diagrams depicting an exemplary embodiment of each of the virtual multiprocessing context registers of Figure 4;

FIG. 6 is a flowchart describing a method for dynamic allocation of virtual processor resources according to the present invention; and

FIG. 7 is a flow chart depicting a revocable method for dynamic allocation of virtual processor resources in accordance with the present invention.

【Detailed ways】

The following description is presented to those skilled in the art to make and use the invention as within the context of a particular application and its requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art, and the general principles defined therein will be applicable to other embodiments. Thus, the present invention is not intended to be limited to the particular embodiments described and shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. With the background discussion above regarding parallel processing and related multithreading and multiprocessing techniques employed in current processors in mind, the discussion of the present invention will be presented with reference to FIGS. 1-7 .

Referring to FIG. 1, there is shown a block diagram of a multiprocessing environment 100 in accordance with the present invention. The multiprocessing environment 100 includes a virtual multiprocessor 101 connected to a system interface controller 105 . The system interface controller 105 is connected to a system memory 106 and to one or more input/output devices 107 . Each I/O device 107 provides an interrupt request line 108 to the virtual multiprocessor 101 . The virtual multiprocessor 101 includes one or more virtual processing elements 102 . Each virtual processing element 102 has a corresponding virtual processing element context 104 and one or more corresponding thread contexts 103 . The multiprocessing environment 100 may be, but is not limited to, a general-purpose programmable computer system, server computer, workstation computer, personal computer, notebook computer, personal digital assistant, or embedded system, such as, but not limited to, a Network routers or switches, printers, mass storage controllers, cameras, scanners, automotive controllers, and more.

The system memory 106 can be embodied as a memory, such as a dynamic random access memory RAM and a read-only memory ROM, for storing program instructions executed by the virtual multiprocessor 101, and for storing instructions to be processed by the virtual multiprocessor 101 according to the program instructions. The data. Program instructions may include one or more program threads that are executed concurrently by virtual multiprocessor 101 . A program thread or thread comprises a sequence or stream of program instructions and associated sequence of state changes within corresponding virtual processing elements 102 in virtual multiprocessor 101, the sequence of state changes being related to the execution of the sequence of instructions. Each thread context 103 includes the hardware state required to support execution of the corresponding program thread. In one embodiment, each thread context includes a set of general-purpose registers, a program counter, and other registers that hold the state of the executing thread, such as multiplier state and coprocessor state. Each virtual processing element 102 provides resources to support an instance of a full instruction set architecture and privileged resource architecture sufficient to execute a single full processor operating system image. In one embodiment, each virtual processing element 102 provides resources to support an instance of a full MIPS32/MIPS64 instruction set architecture and privileged resource architecture. Each virtual processing element context 104 constitutes a hardware state required to support thread execution in a corresponding virtual processing element 102 . In one embodiment, each virtual processing element context 104 specifies resources allocated to a corresponding virtual processing element 102, such as address translation logic resources (e.g., translation lookaside buffer inputs), functional units (e.g., integer units, floating point unit, multimedia unit, media acceleration unit, SIMD unit, coprocessor) and performance attributes. In a particular embodiment, the performance attributes include the ability to stop and configure resources allocated to other virtual processing elements 102, the number of thread enumerations, activation/deactivation of corresponding virtual processing elements 102 and bandwidth-related parameters of virtual multiprocessors 101. Resources (eg, instruction execution bandwidth or priority, load-store bandwidth, etc.), which are allocated to corresponding virtual processing elements 102 . The present invention provides various bandwidth allocation techniques including scheduling hints, execution priority assignment, load/store buffer allocation, etc.

The system interface controller 105 and the virtual multiprocessor 101 are connected to each other via a processor bus. In one embodiment, system interface controller 105 includes a memory controller to control system memory 106 . In one embodiment, the system interface controller 105 includes a local bus interface controller to provide a local bus, eg, a PCI bus, to the I/O device 107 .

The input/output devices 107 may include, but are not limited to, user input devices such as keyboards, mice, scanners, etc.; display devices such as monitors, printers, and the like. Storage devices, such as disk drives, tape drives, optical drives, etc.; system peripherals, such as direct memory access controllers DMAC, clocks, timers, input/output ports, etc.; network devices, such as for Ethernet , fiber optic network, infiniband, or other high-speed network interface media access controller MAC; data conversion devices, such as analog-to-digital converters, digital-to-analog converters, and so on. The I/O device 107 generates an interrupt signal 108 to the virtual multiprocessor 101 to request service. Advantageously, virtual multiprocessor 101 is capable of concurrently executing many program threads for processing events indicated on interrupt request lines 108, without the need for conventional and preserved microprocessor 102 state, transfer of control to interrupt service routines, and Overhead associated with restoring status after completion of an interrupt service routine.

In one embodiment, virtual multiprocessor 101 provides two different, but not mutually exclusive, multithreading capabilities. First, a virtual multiprocessor includes one or more virtual processing elements (VPEs) 102 to support a corresponding one or more logical processor contexts, via resource sharing in the virtual multiprocessor 101, each logical processor context Presented to the operating system is an individual processing element. To an operating system, a virtual multiprocessor 101 with N VPEs 102 looks like an N-way symmetric multiprocessor (SMP), which allows the existence of an SMP-operable operating system to manage one or more VPEs 102. Second, each VPE 102 can include one or more thread contexts 103 to simultaneously execute corresponding one or more program threads. Thus, in accordance with the present invention, virtual multiprocessor 101 provides a multithreaded programmatic model in which, in typical cases, program threads can be spawned and destroyed without operating system intervention, and system service threads can be processed with minimal interruption. Wait times are scheduled in response to external conditions (eg, input/output service event signals).

In one embodiment, each thread context includes one or more storage elements, such as registers or latches, with fields (eg, bits) therein that describe the execution state of the corresponding thread. That is, a given thread context 103 describes the state of the respective thread that is unique to that thread, rather than a state that is shared with other threads executing concurrently on the virtual processing element 102 . A thread, also referred to herein as a program thread, thread of execution, or instruction stream, is a sequence of instructions. Each virtual processing element 102 is capable of processing many threads simultaneously. By storing the state of each thread within the thread context 103, each virtual processing element 102 in the virtual multiprocessor 101 is configured to quickly switch between threads to fetch and issue instructions. Advantageously, the virtual multiprocessor 101 of the present invention is configured to execute instructions to move thread context information between different thread contexts 103, as in co-pending U.S. Patent Application (Docket No.: MIPS.0194-00-US), Its title "Mechanisms for Software Management of Multiple Computing Contexts" is described in detail.

In one embodiment, each VPE context 104 includes a group of storage elements, such as registers or latches, with fields (e.g., bits) that describe the execution state of the corresponding VPE 102, providing resources for the corresponding VPE 102 Configurations such as, but not limited to, address translation resources, co-processing resources (e.g., floating point processors, media processors, etc.), thread capacity and enumeration, specific VPE 102 activation/inhibition of execution permissions, and configuration specific VPE 102 resource permission. In one embodiment, a VPE 102 can configure its own resources by updating its VPE context 104. In addition, a VPE 102 can configure resources of different VPEs 102 by updating the VPE context 104 corresponding to different VPEs 102. Therefore, a virtual multiprocessor 101 with N VPEs 102 appears to the operating system or other symmetric multiprocessing applications as an N-way symmetric multiprocessor. In one embodiment, VPE 102 shares resources specific to virtual multiprocessor 101, such as instruction caches, instruction fetchers, instruction decoders, instruction issuers, instruction schedulers, execution units, and coprocessing units, and Data storage is obvious to the operating unit. The scope and degree of resource sharing is specified by the VPE context 104 and can be dynamically configured at runtime or otherwise by updating the VPE context 104 . For a given VPE 102 to configure its own resources, or to provide resources for other VPEs 102, his own VPE context 104 must specify that the given VPE 102 is allowed to configure the resources of the virtual multiprocessor 101, in There will be a more detailed description below. Therefore, if the VPE context 104 of a given VPE 102 indicates that the given VPE 102 is allowed to configure resources, then the given VPE 102 can update all VPE contexts 104 to provide dynamic resource configuration, including resource configuration permissions. Modifications, including the ability to revoke configuration permissions. In one embodiment, each VPE 102 substantially conforms to a MIPS32 or MIPS64 instruction set architecture (ISA) and a MIPS Privileged Resource Architecture (PRA), and each VPE context 104 includes the MIPS PRA coprocessor 0 and describes its An example of the desired system state. In one embodiment, VPE context 106 includes VPECONTROL register 504 , VPECONF0 register 505 , VPECONF1 register 506 , and VPESCHEDULE register 592 as depicted in FIGS. 5D-5G . In one aspect, a VPE 102 can be thought of as an exception domain. That is, when a thread context 103 of the VPE 102 produces an exception, the multi-threading on the VPE 102 is suspended (that is, only the instruction of the instruction stream associated with the exception of the thread context 104 service is fetched and issued), and every A VPE context 104 includes the state needed to service the exception. Once the exception is serviced, the exception handler will selectively restart multiple threads on the VPE 102.

Referring now to FIG. 2, which is a block diagram illustrating a virtual multiprocessor pipeline 200 within a virtual multiprocessor in accordance with the present invention. The pipeline 200 includes a number of pipeline stages and additionally includes one or more thread contexts 103 . The exemplary embodiment of FIG. 2 shows four thread contexts 103 . In one embodiment, each thread context 103 includes a program counter (PC) 222 for storing the address of the next instruction to be fetched in the associated instruction stream, and a general purpose register (GPR) set 224 for storing Values of counters 222 , intermediate execution results of instruction streams issued from threads, and other per-thread context 226 . In one embodiment, the pipeline 222 includes a multiplier unit (not shown), and the other thread contexts 226 include registers for storing the results of the multiplier unit that are particularly relevant to multiply instructions in the instruction stream. In one embodiment, other thread contexts 226 include information for uniquely identifying each thread context 103 . In one embodiment, the thread identification information includes information specifying the execution privilege level of the associated thread, eg, whether the thread is a kernel, supervisor, or user-level thread. In one embodiment, the thread identification information includes information identifying a task or process that makes up the thread. In particular, the task identification information can be used as an address space identifier (ASID) to translate real addresses into virtual addresses.

Pipeline 200 includes a scheduler 216 for scheduling many threads to be executed simultaneously by virtual multiprocessor 100 . Scheduler 216 is connected to VMP context 210 , VPE context 104 of FIG. 1 , and other per-thread contexts 226 . In particular, the scheduler 216 is responsible for scheduling fetched instructions from the program counters 222 of the various thread contexts 104 and for dispatching the fetched instructions to the execution units 212 of the virtual multiprocessor 100, as described below. According to the scheduling principles of the virtual multiprocessor 100, the scheduler 216 schedules the execution of threads. Scheduling principles may include, but are not limited to, any of the following scheduling principles. In one embodiment, the scheduler 216 employs a round-robin, or time-division multiplexing, or interleaved scheduling principle, assigning a predetermined number of clock cycles, or instruction issue periods, to each in-order the rout. The round robin principle is useful in an application where fairness is important and basic quality of service is required for certain threads, eg, real-time application threads. In one embodiment, scheduler 216 employs a blocking scheduling principle, wherein scheduler 216 continues to schedule fetches and issues of executing threads until an event occurs that blocks further progress of the thread, e.g., a store miss, a branch Misprediction, a data dependency, or a long-latency instruction. In one embodiment, pipeline 200 includes a superscalar pipeline employing many execution units 212, and scheduler 216 schedules the issue of many instructions per clock cycle, and in particular, instruction issues from multiple threads per clock cycle are typically Think of it as simultaneous multithreading. In other embodiments, the scheduler 216 employs a scheduling policy that utilizes scheduling information provided via the VPE context 104, wherein the scheduling information indicates the bandwidth and/or bandwidth-related resources allocated to each VPE 102.

Pipeline 200 includes an instruction cache 202 for storing program instructions fetched from a system memory. In one embodiment, pipeline 200 provides virtual memory capabilities, and fetch unit 204 includes a translation lookaside buffer (not shown) for storing actual to virtual memory page translations. In this embodiment, resources (eg, entries) in the translation lookaside buffer are allocated to each VPE 102 of the shared pipeline 200, as specified by the VPE context 104. In one embodiment, each program or task executing within pipeline 200 is assigned a unique task ID, or address space ID (ASID), which is used to perform memory accesses, and specifically memory addresses Transformation, and a thread context 103, also includes storing the ASID associated with the thread.

Pipeline 200 also includes a fetch unit 204 coupled to instruction cache 202 for fetching program instructions from instruction cache 202 and system memory. The fetch unit 204 fetches addresses from the instruction fetch addresses provided by the multiplexer 244 . The multiplexer 244 receives a plurality of instruction fetch addresses from the corresponding plurality of program counters 222 . Each program counter 222 stores the current instruction fetch address for a different program thread. The embodiment of FIG. 2 illustrates four different program counters 222 associated with four different threads. Multiplexer 244 selects one of four program counters 222 upon a select input provided by scheduler 216 . In one embodiment, different threads executing on the microprocessor 100 share the fetch unit 204 .

The pipeline 200 also includes a decode unit 206 connected to the fetch unit 204 for decoding program instructions fetched by the fetch unit 204 . Decode unit 206 decodes opcodes, operands, and other fields of instructions. In one embodiment, different threads executing on the microprocessor 100 share one decoding unit 206 .

The pipeline 200 also includes an execution unit 212 for executing instructions. Execution units 212 may include, but are not limited to, one or more integer units for performing integer arithmetic, Boolean operations, shift operations, rotation operations, etc.; floating point units for performing floating point operations; a load/store unit for fetching and in particular access to the data cache 242 connected to the execution unit 212; a multimedia acceleration unit for performing multimedia operations; and a branch resolution unit for resolving the result and target address of a branch instruction . In one embodiment, data cache 242 includes a translation lookaside buffer for storing actual to virtual memory page translations. In addition to operands received from data cache 242 , execution units 212 also receive operands from registers of general register file 224 . Specifically, an execution unit 212 receives operands from the register bank 224 of the thread context 104 assigned to the thread to which the instruction belongs. A multiplexer 248 selects operands from the appropriate register bank 224 to provide to the execution unit 212 . Additionally, multiplexer 248 receives data from another thread context 226 and program counter 222 to selectively provide to execution unit 212 based on the thread context 104 of the instruction being executed by execution unit 212 . In one embodiment, different execution units 212 may simultaneously execute instructions from multiple concurrent threads.

The pipeline 200 also includes an instruction issuing unit 208, the instruction issuing unit 208 is connected to the scheduler 216, and is connected between the decoding unit 206 and the execution unit 212, and is used to issue instructions to the execution unit 212 according to the instruction of the scheduler 216, and The response is information about the instruction decoded by the decode unit 206 . In particular, the instruction issue unit 208 ensures that instructions are not issued to the execution unit 212 if the instruction has data dependencies on other instructions previously issued to the execution unit 212 . In one embodiment, an instruction queue (not shown in the figure) is placed between the decoding unit 206 and the instruction issuing unit 208, and is used for buffering instructions waiting to be issued to the execution unit 212, so as to reduce the exhaustion of the execution unit 212. possibility. In one embodiment, the instruction issue unit 208 is shared by many thread executions in the pipeline 200 .

Pipeline 200 also includes a writeback unit 214 coupled to execution unit 212 for writing the results of instructions back to general register set 224 , program counter 222 , and other thread contexts 226 . A demultiplexer 246 receives the instruction result from the writeback unit 214 and stores the instruction result in the appropriate register file 224, program counter 222, and other thread context 226 associated with the instruction's thread. The instruction result is also provided for storage to VPE context 104 and a virtual multiprocessor (VMP) context 210 .

In one embodiment, VMP context 210 includes a set of storage elements, such as registers or latches, in which one or more fields (eg, bytes) describe the execution state of virtual multiprocessor 101 . In particular, VMP context 210 stores state about all resources of virtual multiprocessor 101 that are shared within VPE 102, as described above. Specifically, the VMP context specifies the resources that can be allocated to the VPEs 102 during configuration, and also controls whether the virtual multiprocessor 101 is in a configuration state that configures these resources. In one embodiment, the VMP context 210 includes a MVPCONTROL register 501 , MVPCON0 register 502 , and MVPCON1 register 503 as described below in FIGS. 5A-5C .

The specific stages 202, 204, 206, 208, 212, 214 of the pipeline 200 shown in Figure 2 are provided to clearly illustrate the invention without obscuring substantive aspects. Those skilled in the art will appreciate that the phasing of pipeline 200 may be modified to enhance performance by increasing or decreasing the number of stages, or by assigning different functions to the stages, without departing from the spirit and scope of the invention.

Referring to FIG. 3, a block diagram of a dynamically configurable virtual multiprocessor 300 according to the present invention is shown. The multiprocessor 300 includes one or more VPEs 302-304, enumerated as VPE 1302, VPE 2 303, up to VP N 304. Each VPE 302-304 has a corresponding VPE context 305-307. The VPEs 302-304 and VMP context 210 are connected to execution logic 212, as described above with reference to FIG. 2 . The execution logic 212 includes VPE configuration logic 310 . The VPE configuration logic 310 is connected to an exception signal 311 . Also shown in the block diagram are one or more resources 322, 324, 326, 328, listed as RESOURCE1 322, RESOURCE2 324, RESOURCE3 326, through RESOURCEM 328, respectively.

In operation, configuration of resources 322-328 is accomplished by executing a sequence of configuration commands issued by VPEs 302-304 that are permitted to configure these resources 322-328. In one embodiment, permissions to configure resources 322-328 are specified by VPE contexts 305-307 of corresponding VPEs 302-304. When a sequence of configuration instructions is received by the execution logic 212 in the pipeline 200, the VPE configuration logic 310 accesses the VPE context 305-307 corresponding to the VPEs 302-304, the program threads of the VPEs 302-304 cause the sequence of configuration instructions to be fetched To determine whether VPEs 302-304 are allowed to configure these resources 322-328. If not, configuration logic 310 causes exception signal 311 to be asserted, and the sequence of configuration instructions is not executed. If the VPEs 302-304 are allowed to configure these resources 322-328, the VPE configuration logic 310 executes a sequence of configuration instructions to direct the virtual multiprocessor 300 into the configuration state, and update one or more specified VPE contexts 305-307, thus, Reconfigure these resources. In one embodiment, a sequence of configure instructions directs virtual multiprocessor 300 to enter a configure state by updating VMP context 210 . In one embodiment, the sequence of configuration instructions includes instructions conforming to the MIPS32/MIPS64 Multithreaded (MT) Application Specific Extensions (ASE) architecture.

The block diagram shows a specific embodiment of configured resources 322-328 resulting from execution of a sequence of configuration instructions, and diagrammatically depicts how specific resources 322-328 can be dynamically configured in accordance with the present invention to optimize The performance of concurrently executing threads in a given multithreaded multiprocessing application. For example, consider that the RESOURCE1 322 icon branch corresponds to an address translation resource (eg, translation lookaside buffer input). As shown from the branch, VPE1 302 is defined as a portion of the address translation resource and is smaller than the portion allocated to the remaining VPEs 303-304. Perhaps, the thread that executes at VPE1 302 is short and repetitive with respect to other thread, therefore, does not need the address translation resource of extensification. Also consider that RESOURCE2 324 represents contexts corresponding to multi-threaded coprocessors (eg, floating point elements, media elements, SIMD elements, etc.). VPE2 303, as specified in its VPE context 306, is configured with a lower number of contexts than the other VPEs 302, 307, perhaps due to the fact that operations directed by instruction threads issued by VPE 2 303 do not require a large amount of sharing. Process resources. Also, consider that RESOURCE3 326 represents a resource configuration license. As the diagram presents, only VPE2 303 is allowed to configure resources 302-304 in virtual multiprocessor 300. That is to say, a given VPE 302-304 (VPE2 303 in this example) that has obtained configuration permissions can grant configuration permissions to other VPEs 302-304, or revoke their configuration permissions, or revoke its own configuration permissions . This is accomplished by updating the provisioned VPE contexts 305-307 as described herein. Considering that RESOURCE M 328 is a bandwidth resource, it allocates the bandwidth of the virtual multiprocessor 300 to its VPEs 302-304 according to an implemented scheduling principle as described above. Thus, the graph shows that each of the exemplary VPEs 302-304 is given the same portion of the multiprocessor bandwidth, either via direct execution bandwidth allocation, or by setting approximately equal execution priorities, or by other means for specifying bandwidth Or technologies for bandwidth-related resources. One such technique for specifying bandwidth-related resources attempted by the present invention is the allocation of load/store bandwidth to VPEs 302-304. For example, if the number of memory arithmetic buffers (not shown) in the virtual multiprocessor 300 shared among the VPEs 302-304 is less than the number of execution threads, then the memory operation buffer associated with a thread of a given VPE 302-304 is executed. Prior to operation, the virtual multiprocessor 300 will evaluate whether to disconnect a given thread because such an operation may exceed the bandwidth-related resource allocation specified for a given VPE 302-304. Such a bandwidth allocation scheme advantageously addresses the small number of threads associated with VPEs 302-304, e.g., the situation where a long chain of store misses could monopolize bandwidth-related resources (not memory op buffers in this example) , thus preventing execution of threads from other VPEs 302-304. Such cases have been excluded from the virtual multiprocessor 300 according to the invention by specifying the allocation of bandwidth-related resources.

Please refer to FIG. 4 , which shows a table 400 depicting virtual multiprocessing context registers according to an exemplary embodiment of the present invention. The virtual multiprocessing context register is employed to configure a virtual multiprocessor context 210, or a virtual processing element context 104, as described above. The virtual multiprocessing context includes registers MVPCONTROL, MVPCONF0, and MVPCONF1. The virtual processing element context for each VPE within a virtual multiprocessor includes registers VPECONTROL, VPECONF0, VPECONF1, and VPESCHEDULE. Table 400 shows registers conforming to MIPS32/MIPS64 instruction set and privileged resource architecture-specific extensions, wherein a CPO register number and register selection number are specified for each of the indicated registers to access contexts therein. The architecture and context of the above registers will be discussed with reference to FIG. 5 .

FIG. 5 is a series of block diagrams depicting an exemplary embodiment of each of the virtual multiprocessor context registers 501-506, 592 of FIG. Figures 5A-5F include descriptions of the fields of each register and a table describing the different fields, particularly relevant fields are discussed in detail here. Each register illustrated in FIG. 5 can be selectively read or written by the VPE. According to the value of the MVP field 553 in the VPECONF0 register 505, the VPE has the permission to dynamically configure these resources. Certain fields in registers 501-506, 592 are writable only by the VPE, and the MVP field 553 of the VPE indicates that it has configuration permissions. Otherwise, certain fields are read-only, as controlled by configuration logic 310 .

The MVPCONTROL register 501 has a STLB field 511 , a VPC field 512 , and an EVP field 513 . A VPE 102 with configuration permissions as described above can update VPC field 512 and EVP field 513 to place virtual multiprocessor 101 in a configuration state for resource configuration. Clearing the VPC field 512 and setting the EVP field 513 causes new resource values to be latched in configuration registers 501-506, 592 and used for virtual processing to start over. A VPE 102 with configuration permission can update the STLB field 511 to share address translation resources.

MVPCONF0 register 502, and MVPCONF1 register 503 are read-only registers which are read by a VPE 102 with configuration permission to determine the number and extent of configurable resources set in a given virtual multiprocessor 101. The field TLBS indicates that the address translation resource can be shared, and the address translation resource sharing can be configured by setting the field STLB511 of the MVPCONTROL register 501 . Field PVPE 524 specifies the total number of VPEs 102 provided by the virtual multiprocessor 101. In the embodiment of FIG. 5, up to 16 VPEs 102 may be employed. Field PTC525 indicates the total number of thread contexts 103 provided by virtual multiprocessor 101 . In the illustrated embodiment, up to 256 thread contexts 103 will be illustrated. Field C1M 531 indicates that the allocatable coprocessor is multimedia extensible. Field C1F 532 indicates whether the allocatable coprocessor is floating point capable. Fields 533-535 indicate the total number of other ISA-specific resources available for allocation to VPEs 102.

Resources are assigned to a specific VPE 104 by writing the VPE number to the field TARGVPE 334 of the VPECONTROL register 504. One example of writing to field 334 is via the MIPSMTTR and MFTR instructions described above.

The value of field VPA 552 in register VPECONF0 505 is set to activate/deactivate a specified VPE 102. Field MVP 553 is set to grant or cancel resource allocation permission. Fields MINTC 554 and MAXTC 555 are updated to match the number of thread contexts 103 allocated and instantiated to a specified VPE 102. In the MIPS32/MIPS64 multithreaded application-specific extension of the present invention, fields NCX 561, NCP2 562, and NCP1 563 are updated to allocate coprocessor resources to a specific VPE 102. As noted above, the tables of Figures 5E-5F show that the annotated resource allocation fields 552-555, 561-563 are read-only fields. All VPEs 102 have no resource allocation permissions, as indicated by the state of MVP bit 553 in VPECONF0 register 505. For a VPE 102 granted resource configuration permission, configuration logic 310 enables noted fields 552-555, 561-563 to be updated (ie, written to).

Register VPESCHEDULE 592 includes a scheduler hint field 529 that can be updated to configure bandwidth resources across VPEs 102 in virtual multiprocessor 101.

Although Figures 4 and 5 describe an exemplary embodiment of the present invention in which certain resources can be dynamically configured in a MIPS32/MIPS64 multi-threaded application-specific extension environment, the inventor points out that the exemplary embodiment is based on A known instruction set architecture is provided to teach aspects of the invention. The inventor also points out that other architectures may also be included.

Referring to FIG. 6 , there is shown a flowchart 600 illustrating a method for dynamic allocation of virtual processor resources according to the present invention. The method starts at block 602, where, according to the present invention, a VPE wants to dynamically allocate these resources. Flow proceeds to block 604 .

At block 604, the VPE context corresponding to the requested VPE is read. Flow proceeds to decision block 606 .

At decision block 606, the VPE context is evaluated to determine whether the requesting VPE is allowed to dynamically allocate the resources in the virtual multiprocessor. If yes, flow proceeds to block 608 . If not, the process proceeds to block 607.

At block 607 , an exception is declared and flow proceeds to block 620 because the requesting VPE does not have resource allocation permission.

At block 608, virtual processing in the virtual multiprocessor is disabled to allow resource allocation. Flow proceeds to block 610 .

At block 610, a configuration state is established in the virtual multiprocessor. Flow proceeds to block 612 .

At block 612, a VMP context within the virtual multiprocessor is accessed to determine what and how many resources are available for configuration. Flow proceeds to block 614 .

At block 614, a target VPE is selected for configuration of its allocated resources. Flow proceeds to block 616 .

At block 616, the resources are configured for the selected VPE by updating its corresponding VPE context. Flow proceeds to block 618 .

At block 618, the new configuration of resources for the selected VPE is latched by exiting the configuration state, and virtual processing in the virtual multiprocessor is restarted. Flow proceeds to block 620 .

At block 620, the method is complete.

FIG. 7 is a flowchart 700 depicting a retractable method for dynamic allocation of virtual processor resources in accordance with the present invention. All of the blocks 702-720 of the flowchart 700 of FIG. 7 are identical to the corresponding blocks 602-620 of the flowchart 600 of FIG. , the VPE context of the selected VPE is updated to revoke its permission to dynamically configure these resources. The requesting VPE of block 702 may be the same as the selected VPE of block 717, therefore, starting a VPE revokes its own configuration permission. After latching the new configuration in block 718, the requesting VPE can no longer configure these resources.

Although the invention and its objects, features, and advantages have been described in detail, other embodiments are encompassed by the invention. For example, in addition to the implementation of the present invention using hardware, the present invention can also be embodied in software (e.g., computer readable code, program code, instruction and/or data) to achieve. Such software enables the functioning, fabrication, modeling, simulation, description and/or testing of the devices and methods described herein. For example, it may be implemented using common programming languages (e.g., C, C++, JAVA, etc.), GDSII databases, hardware description languages (HDL) including Verilog HDL, VHDL, etc., or other available programs, databases, and/or Circuit (ie, schematic) capture tool to complete. Such software can be deployed on any known computer-usable (e.g., readable) media, including semiconductor memory, magnetic disks, optical disks (e.g., CD-ROM, DVD-ROM, etc.), and as a A computer data signal in a computer-usable (eg, readable) transmission medium (eg, carrier wave or other media including digital, optical, or analog-based media). Such software can be transmitted over communication networks including the Internet and intranets. The present invention can be implemented in software (e.g., in HDL as part of a semiconductor intellectual property core, such as a microprocessor core, or in a system-level design, such as a system-on-a-chip or SOC) and converted to hardware as an integrated circuit product part. The present invention can also be implemented by a combination of software and hardware.

Finally, those skilled in the art will appreciate that they may use the concepts and specific embodiments disclosed herein as a basis for designing or modifying other architectures for carrying out the same purposes of the present invention without departing from the principles defined in the appended claims spirit and scope of the invention.

Claims (69)

1, a kind of device that is used to the one or more virtual treatment element resource allocation in the dummy multiprocessor, it comprises:

A dummy multiprocessor context is used to stipulate these resources, and is used to control a configuration status of this dummy multiprocessor;

One or more virtual treatment element contexts, each ad hoc corresponds in these one or more virtual treatment elements one, and described each virtual treatment element context comprises:

First logic is used for stipulating whether described of these one or more virtual treatment elements is allowed to dispose these resources; And

Second logic is used to stipulate to be assigned to described in these one or more virtual treatment elements a subclass of one resource; And

Configuration logic, be connected to described dummy multiprocessor context and described one or more virtual treatment element context, whether described one that is used for detecting described one or more virtual treatment elements be allowed to dispose these resources, be used to upgrade described dummy multiprocessor context and enter described configuration status, and be used for disposing these resources by the virtual treatment element context that upgrades a regulation to indicate this dummy multiprocessor.

2, device according to claim 1, wherein these one or more virtual treatment elements are carried out in this dummy multiprocessor simultaneously, and wherein this dummy multiprocessor shows as a symmetric multiprocessor to a symmetrical multiprocessing operating system.

3, device according to claim 1, wherein each of these one or more virtual treatment elements comprises one or more thread context, these thread context are configured to and carry out one or more threads simultaneously.

4, device according to claim 3, wherein these one or more thread context described each share resource of configuration, the resource of wherein said configuration is assigned to of correspondence these one or more virtual treatment elements from these resources.

5, device according to claim 1, wherein these resources comprise one or more attribute of this dummy multiprocessor, and the mode that described particular virtual treatment element is carried out with respect to every other virtual treatment element in these one or more virtual treatment elements of this dummy multiprocessor is determined in the configuration that wherein is used for the resource of a particular virtual treatment element.

5, device according to claim 1, wherein these resources comprise conversion look ahead buffer attribute.

6, device according to claim 1, wherein these resources comprise the coprocessing attribute.

7, device according to claim 1, wherein these resources comprise the floating-point processing attribute.

8, device according to claim 1, wherein these resources comprise that medium quicken attribute.

9, device according to claim 1, wherein these resources comprise the permission of disposing these resources.

10, device according to claim 1, wherein these resource packet vinculum journey contexts.

11, device according to claim 1, wherein these resources comprise the bandwidth of this dummy multiprocessor.

12, device according to claim 1, wherein these resources comprise that virtual treatment element starts.

13, device according to claim 1, wherein each of these one or more virtual treatment elements comprises an illustration and the privileged resource framework of MIPS32/MIPS64 instruction.

14, device according to claim 1, the virtual treatment element context of wherein said regulation correspond to described in these one or more virtual treatment elements one.

15, device according to claim 14, the wherein permission that can cancel its these resources of configuration described in these one or more virtual treatment elements.

16, device according to claim 1, the virtual treatment element context of wherein said regulation correspond to not same in these one or more virtual treatment elements.

17, device according to claim 16, the wherein described permission that can cancel the described not same resource allocation in these one or more virtual treatment elements in these one or more virtual treatment elements.

18, device according to claim 1, wherein said virtual multiprocessing context comprises one or more registers, and wherein said configuration status is worth wherein a configuration status field and Be Controlled by writing one.

19, device according to claim 1, wherein said first logic is included in a main virtual processor field in one or more virtual processor context register, and a particular value of wherein said main virtual processor field stipulates whether described one in described one or more virtual treatment element be allowed to dispose these resources.

20, device according to claim 1, wherein said second logic is included in the one or more fields in one or more virtual processor context register, and wherein said one or more field can only be updated by a given virtual treatment element that is allowed to dispose these resources.

21, device according to claim 20, if wherein described given virtual treatment element is not allowed to dispose these resources, then described configuration logic causes one unusually.

22, device according to claim 1, wherein one or more programmed instruction are performed by described one in described one or more virtual treatment elements, to set up described configuration status and these resources of configuration.

23, a kind of resource distribution mechanism is used for the virtual treatment element that Resources allocation is given a dummy multiprocessor, and this resource distribution mechanism comprises:

A plurality of dummy multiprocessor registers are used to stipulate these resources, and are used to control the configuration status of this dummy multiprocessor;

Each a plurality of virtual treatment element register that is used for these virtual treatment elements, be used to stipulate whether a corresponding virtual treatment element is allowed to assign these resources, and be used to stipulate be assigned to the subclass of the resource of described corresponding virtual treatment element; And

Configuration logic, be connected to described dummy multiprocessor register and described virtual treatment element register, be used to detect the virtual treatment element of described correspondence and whether be allowed to assign these resources, be used to upgrade described dummy multiprocessor register and enter described configuration status, and be used for assigning these resources by upgrading the selected register of described virtual treatment element register to indicate this dummy multiprocessor.

24, mechanism according to claim 23, wherein these resources comprise conversion look ahead buffer attribute.

25, mechanism according to claim 23, wherein these resources comprise the coprocessing attribute.

26, mechanism according to claim 23, wherein these resources comprise the floating-point processing attribute.

27, mechanism according to claim 23, wherein these resources comprise that medium quicken attribute.

28, mechanism according to claim 23, wherein these resources comprise the permission of disposing these resources.

29, mechanism according to claim 23, wherein these resource packet vinculum journey contexts.

30, mechanism according to claim 23, wherein these resources comprise the bandwidth of this dummy multiprocessor.

31, mechanism according to claim 23, wherein these resources comprise that virtual treatment element starts.

32, mechanism according to claim 23, wherein each in these virtual treatment elements comprises an illustration and the privileged resource framework of MIPS32/MIPS64 instruction.

33, mechanism according to claim 23, the virtual treatment element of wherein said correspondence can be cancelled the permission of its these resources of assignment.

34, mechanism according to claim 23, the virtual treatment element of wherein said correspondence can be cancelled and be the not permission of same resource allocation in these virtual treatment elements.

35, a kind of computer program that uses with a calculation element, this computer program comprises:

The spendable medium of computing machine have the program code that is included in the embodied on computer readable in the described medium, are configured to and describe the device that is used to the virtual treatment element resource allocation in the dummy multiprocessor, and the program code of described embodied on computer readable comprises:

First program code is configured to and describes a dummy multiprocessor context, and described resource stipulated in this dummy multiprocessor context, and be used to control a configuration status of described dummy multiprocessor;

Second program code, be configured to and describe virtual treatment element context, in the ad hoc corresponding described virtual treatment element of each virtual treatment element context one, and stipulate whether described one in the described virtual treatment element be allowed to dispose described resource, and regulation is assigned to described in the described virtual treatment element subclass of one described resource; And

The 3rd program code, be configured to the description configuration logic, described configuration logic is connected to described dummy multiprocessor context and described virtual treatment element context, whether described one that is used for detecting described virtual treatment element be allowed to dispose described resource, be used to upgrade described dummy multiprocessor context and enter described configuration status, and be used for disposing described resource by the virtual treatment element context that upgrades a regulation to indicate described dummy multiprocessor.

36, computer program according to claim 35, wherein said resource comprises one or more attributes of described dummy multiprocessor, and the mode that the virtual treatment element of described regulation is carried out with respect to the every other element in the described virtual treatment element of described dummy multiprocessor is determined in the configuration of described resource that wherein is used for the virtual treatment element of described regulation.

37, computer program according to claim 35, wherein said resource comprise conversion look ahead buffer attribute.

38, computer program according to claim 35, wherein said resource comprises the coprocessing attribute.

39, computer program according to claim 35, wherein said resource comprises the floating-point processing attribute.

40, computer program according to claim 35, wherein said resource comprise that medium quicken attribute.

41, computer program according to claim 35, wherein said resource comprises the permission of disposing described resource.

42, computer program according to claim 35, wherein said resource packet vinculum journey context.

43, computer program according to claim 35, wherein said resource comprises the bandwidth of described dummy multiprocessor.

44, computer program according to claim 35, wherein said resource comprise that virtual treatment element starts.

45, computer program according to claim 35, each of wherein said virtual treatment element comprise an illustration and the privileged resource framework of MIPS32/MIPS64 instruction.

46, be included in computer data signal in the transmission medium, it comprises:

The program code of embodied on computer readable is configured to and describes the device that is used to the virtual treatment element resource allocation in the dummy multiprocessor, and the program code of described embodied on computer readable comprises:

First program code is configured to and describes a dummy multiprocessor context, and described resource stipulated in described dummy multiprocessor context, and be used to control a configuration status of described dummy multiprocessor;

Second program code, be configured to and describe virtual treatment element context, in the ad hoc corresponding described virtual treatment element of each virtual treatment element context one, and stipulate whether described one in the described virtual treatment element be allowed to dispose described resource, and regulation is assigned to a subclass of described one the described resource in the described virtual treatment element; And

The 3rd program code, be configured to the description configuration logic, described configuration logic is connected to described dummy multiprocessor context and described virtual treatment element context, be used to detect described in the described virtual treatment element one and whether be allowed to dispose described resource, be used to upgrade described dummy multiprocessor context and enter described configuration status, and be used for disposing described resource by the virtual treatment element context that upgrades a regulation to indicate described dummy multiprocessor.

47, according to the described computer data signal of claim 46, wherein said resource comprises one or more attributes of described dummy multiprocessor, and the mode that the virtual treatment element of described regulation is carried out with respect to the every other element in the described virtual treatment element of described dummy multiprocessor is determined in the configuration of described resource that wherein is used for the virtual treatment element of described regulation.

48, according to the described computer data signal of claim 46, wherein said resource comprises conversion look ahead buffer attribute.

49, according to the described computer data signal of claim 46, wherein said resource comprises the coprocessing attribute.

50, according to the described computer data signal of claim 46, wherein said resource comprises the floating-point processing attribute.

51, according to the described computer data signal of claim 46, wherein said resource comprises that medium quicken attribute.

52, according to the described computer data signal of claim 46, wherein said resource comprises the permission of disposing described resource.

53, according to the described computer data signal of claim 46, wherein said resource packet vinculum journey context.

54, according to the described computer data signal of claim 46, wherein said resource comprises the bandwidth of described dummy multiprocessor.

55, according to the described computer data signal of claim 46, wherein said resource comprises that virtual treatment element starts.

56, according to the described computer data signal of claim 46, each in the wherein said virtual treatment element comprises an illustration and the privileged resource framework of MIPS32/MIPS64 instruction.

57, a kind of method that is used to the virtual treatment element resource allocation in the dummy multiprocessor, this method comprises:

Via a dummy multiprocessor context, at first stipulate these resources, and control a configuration status of this dummy multiprocessor;

Via virtual treatment element context, each virtual treatment element context ad hoc corresponds in these virtual treatment elements, second stipulates whether one in these virtual treatment elements be allowed to dispose these resources, and the 3rd regulation is tasked a subclass of these these resources in these virtual treatment elements by branch; And

Be connected to this dummy multiprocessor context and the contextual configuration logic of this virtual treatment element via connection, whether this that detects in these virtual treatment elements be allowed to dispose these resources, and first upgrade this dummy multiprocessor context and enter described configuration status to indicate this dummy multiprocessor, and dispose these resources by the second virtual treatment element context that upgrades a regulation.

58, according to the described method of claim 57, wherein said second renewal comprises the one or more attributes that distribute this dummy multiprocessor.

59, according to the described method of claim 58, wherein said distribution comprises: assign conversion look ahead buffer attribute.

60, according to the described method of claim 58, wherein said distribution comprises: assign the coprocessing attribute.

61, according to the described method of claim 58, wherein said distribution comprises: assign the floating-point processing attribute.

62, according to the described method of claim 58, wherein said distribution comprises: assign medium and quicken attribute.

63, according to the described method of claim 58, wherein said distribution comprises: the permission of assigning these resources of configuration.

64, according to the described method of claim 58, wherein said distribution comprises: assign thread context.

65, according to the described method of claim 58, wherein said distribution comprises: the bandwidth of assigning this dummy multiprocessor.

66, according to the described method of claim 58, wherein said distribution comprises: start a given virtual treatment element.

67, according to the described method of claim 57, wherein each of these virtual treatment elements comprises an illustration and the privileged resource framework of MIPS32/MIPS64 instruction.

68, a kind of virtual multiprocessing system, it comprises:

A storer is configured to and stores the programmed instruction relevant with a plurality of program threads; And

A dummy multiprocessor, be connected to described storer, be configured to and carry out described programmed instruction on the one or more virtual treatment element in described dummy multiprocessor, wherein said dummy multiprocessor has the resource of the configuration of the described one or more virtual treatment elements of regulation, and the dummy multiprocessor context of controlling a configuration status of described dummy multiprocessor, wherein said one or more virtual treatment elements comprise:

A virtual treatment element context, be used to stipulate described one or more virtual treatment elements whether described each be allowed to dispose described resource, and be used for stipulating being assigned to a subclass of one the described resource that described one or more virtual treatment element stipulates; And

Configuration logic, be connected to described dummy multiprocessor context and described virtual treatment element context, be used to detect described one or more virtual treatment elements described each whether be allowed to dispose described resource, be used to upgrade described dummy multiprocessor context and enter described configuration status, and the virtual treatment element context that is used for corresponding to by renewal one 's of stipulating described in described one or more virtual treatment element a regulation disposes described resource to indicate described dummy multiprocessor.

Images