Conditional Yield to Hypervisor Instructions

Abstract

The apparatus includes a processing circuit (16) having a hypervisor execution mode for execution of a hypervisor for managing one or more virtual processors executing on the processing circuit and at least one execution mode less privileged than the hypervisor execution mode. In response to a conditional yield for a hypervisor instruction executed in the at least one less privileged execution mode, an instruction decoder (14) controls the processing circuit (16) to determine whether at least one trap condition is satisfied, switch the processing circuit to the hypervisor execution mode upon determining that the at least one trap condition is satisfied, and store, in at least one storage element accessible to instructions executed in the hypervisor execution mode, at least one item of scheduling hint information for estimating whether the at least one trap condition is still satisfied.

Description

[Technical field]

[0001] The present technology relates to the field of data processing. Summary of the Invention [Problem to be solved by the invention]

[0002] In a virtualized data processing system, a hypervisor can manage one or more virtual processors that execute on physical processing circuitry. The virtual processors can be mapped by the hypervisor onto the resources of a physical processing platform, which may include one or more physical processor cores. The hypervisor can support the execution of multiple virtual machines, where each virtual machine can request that the hypervisor create a given number of virtual processors for that virtual machine, where each virtual processor emulates the behavior of a physical processor core. The hypervisor can manage the mapping between the virtual resources required by a given virtual processor and the physical resources actually provided in the hardware, as well as control the scheduling of each virtual processor to control when each virtual processor is assigned processing resources.

[0003] At least some embodiments provide an apparatus comprising a processing circuit for performing data processing; and an instruction decoder for controlling the processing circuit to decode instructions for performing the data processing, wherein the processing circuit has a hypervisor execution mode for execution of a hypervisor for managing one or more virtual processors executing on the processing circuit, and at least one less privileged execution mode than the hypervisor execution mode, and in response to a conditional yield for a hypervisor instruction executed in the at least one less privileged execution mode, the instruction decoder is configured to control the processing circuit to determine whether at least one trap condition is satisfied, and upon determining that the at least one trap condition is satisfied, switch the processing circuit to the hypervisor execution mode, and store, in at least one storage element accessible to instructions executed in the hypervisor execution mode, at least one item of scheduling hint information for estimating whether the at least one trap condition is still satisfied.

[0004] At least some embodiments provide a data processing method for an apparatus having a processing circuit having a hypervisor execution mode for execution of a hypervisor for managing one or more virtual processors executing on the processing circuit and at least one less privileged execution mode than the hypervisor execution mode, the method including: decoding a conditional yield for a hypervisor instruction executed in the at least one less privileged execution mode; determining whether at least one trap condition is satisfied in response to decoding the conditional yield for the hypervisor instruction; switching the processing circuit to the hypervisor execution mode upon determining that the at least one trap condition is satisfied; and storing, in at least one storage element accessible to instructions executed in the hypervisor execution mode, at least one item of scheduling hint information for estimating whether the at least one trap condition is still satisfied.

[0005] At least some embodiments provide a computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing instructions, the computer program including instruction decode program logic for controlling the host data processing apparatus to decode instructions of a target code executed within the instruction execution environment to perform data processing corresponding to instructions of the target code, the instruction execution environment having a hypervisor execution mode for execution of a hypervisor for managing one or more virtual processors executing within the instruction execution environment and at least one less privileged execution mode than the hypervisor execution mode, wherein in response to a conditional yield for a hypervisor instruction of the target code executed in the at least one less privileged execution mode, the instruction decode program logic is configured to control the host data processing apparatus to determine whether at least one trap condition is satisfied and, upon determining that the at least one trap condition is satisfied, switch the instruction execution environment to the hypervisor execution mode and store, in at least one data structure accessible to instructions of the target code executed in the hypervisor execution mode, at least one item of scheduling hint information for estimating whether the at least one trap condition is still satisfied.

[0006] A storage medium may be provided that stores the above-mentioned computer program. The storage medium may be a non-transitory storage medium.

[0007] Further aspects, features, and advantages of the present technology will become apparent from the following description of examples, which should be read in conjunction with the accompanying drawings. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 illustrates a schematic diagram of an example data processing system. [Diagram 2] FIG. 2 shows an example of different execution modes with different privileges, including a hypervisor mode. [Diagram 3] FIG. 3 shows an example of some of the architectural registers of a processor core. [Figure 4] FIG. 4 shows an example of a two-stage address translation. [Diagram 5] FIG. 5 is a flow diagram illustrating a method for processing a load exclusive instruction. [Figure 6] FIG. 6 is a flow diagram illustrating the tracing of accesses to a trace address by an exclusion monitor. [Figure 7] FIG. 7 shows an example of a conditional yield for a hypervisor instruction. [Figure 8] FIG. 8 is a flow diagram illustrating a method for handling a conditional yield for a hypervisor instruction. [Figure 9] FIG. 9 is a flow diagram showing more detailed steps for determining whether a trap condition is met for a conditional yield on a hypervisor instruction. [Figure 10] FIG. 10 is a flow diagram showing more detailed steps for storing scheduling hint information in response to a conditional yield for a hypervisor instruction. [Figure 11] FIG. 11 shows an example of a simulator that may be used. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] In some processing workloads, a currently executing process may not be able to proceed forward until some event occurs or a condition is met, such as a data value at a given address in memory being set to a particular value. For example, this may be the case when a lock variable is used to control access to a data structure in memory, where one process may need to wait to use the data structure until the lock variable is cleared by another process to indicate that the other process is no longer using the same data structure. This may be useful to enforce exclusive access to ensure that updates to the data structure are made automatically.

[0010] In a virtualization system, a process that is still waiting for some condition to be satisfied may voluntarily relinquish control of the processing circuitry to the hypervisor to allow the hypervisor to reschedule a different virtual processor if possible, so that physical processing resources can be used for useful work while the yielding virtual processor is waiting. However, it may be relatively difficult for the hypervisor to know which virtual processor to schedule next, since the exact workload of each virtual processor is not generally known by the hypervisor. There may be little benefit in the hypervisor selecting to run a virtual processor that is currently unable to make full progress.

[0011] Some processing workloads may use a queued locking mechanism, where processors may use a queue structure to manage the order in which they can access a shared resource. When a hypervisor is scheduling virtual processors using queued locks, it may be important to schedule virtual processors in the order in which they arrive in the queue, so that physical processing resources are not wasted executing virtual processors that cannot make forward progress. Similarly, there is little point in scheduling a virtual processor that is waiting to read a variable controlled by a lock where the lock is already held by a writer.

[0012] One approach to address this issue may be to use paravirtualization, where the hypervisor may provide services for implementing concurrent data structures such as locks or queues, or even services directed at yielding to a particular virtual processor. In these approaches, the virtual machine and the hypervisor may communicate with each other via a shared data structure in memory (e.g., a queue), which may be used to track locks and thereby allow the hypervisor to determine whether a given virtual processor is likely to make forward progress. However, this approach has several drawbacks. First, this approach is inherently non-portable between different hypervisor implementations, since a given piece of virtual machine code must include instructions to interact with a particular form of control data structure provided by the particular hypervisor on which it is executed. Thus, each time a new concurrent algorithm is implemented, this will require an extension of the code of a given virtual machine. This approach also requires collaboration between the developer of the hypervisor code and the virtual machine code, which may increase complexity and development costs. Also, this paravirtualization may be disadvantageous in terms of performance because it may rely on unconditional traps to the hypervisor, which may add significant overhead in less-than-scribing systems where there are relatively few other virtual processors competing for the use of processing resources provided by the hardware. Also, in some architectures, explicit calls to the hypervisor may not be permitted for user mode code, so application level software often may not be able to use these paravirtualization interfaces in any way. Also, access to such concurrent data structures may require additional address translation overhead from both the hypervisor and the virtual machine.

[0013] In the techniques discussed below, architectural support is provided for conditional yield on hypervisor instructions that allow a given virtual processor to conditionally yield control of processing circuitry to a hypervisor, and also conveys hypervisor scheduling hint information that may enable the hypervisor to determine whether it would be efficient to attempt to reschedule the same virtual processor, thereby avoiding the need for the hypervisor and virtual processor to interact via memory structures such as those described above, thus helping to improve code portability and reduce the performance costs described above.

[0014] Thus, the apparatus may have a processing circuit having a hypervisor execution mode for execution of a hypervisor for managing one or more virtual processors executed by the processing circuit and at least one execution mode having a lower privilege than the hypervisor execution mode. The instruction decoder may support decoding of a conditional yield for a hypervisor instruction that, when executed in the at least one lower privilege execution mode, controls the processing circuit to determine whether at least one trap condition is satisfied. Upon determining that the at least one trap condition is satisfied, the processing circuit is controlled to switch to the hypervisor mode and store, in at least one storage element accessible to instructions executed in the hypervisor mode, at least one item of scheduling hint information for estimating whether the at least one trap condition is still satisfied. Thus, by supporting communication of scheduling hint information to the hypervisor at an architectural level, the virtual machine and the hypervisor do not need to interact via memory to provide the scheduling hint, thereby eliminating the problems mentioned above with paravirtualization.

[0015] The scheduling hint information returned by the processing circuit in response to a conditional yield to a hypervisor instruction may include any information that may enable the hypervisor to make an estimate of whether a trap condition is still satisfied. For example, the scheduling hint information may include values ​​used by the virtual processor to evaluate whether a trap condition is satisfied. For example, if at least one trap condition was to be evaluated based on values ​​in at least one register, the values ​​in the at least one register may be copied to a location accessible to hypervisor instructions, allowing the hypervisor to examine those data values ​​to evaluate the condition.

[0016] However, in practice, registers accessible to the lower privilege execution mode may also be accessible to the hypervisor execution mode, so there may be no need to actually copy the values ​​of those registers between registers. Instead, in some embodiments, the scheduling hint information may include an indication of at least one register specifier specified by a conditional yield for the hypervisor instruction. Because the size of the register specifier may often be smaller than the number of bits in the register itself, this technique can reduce the number of bits written, which may save energy.

[0017] In some systems, the architecture may support registers of different register widths, in which case the scheduling hint information may also include an indication of the register width of the at least one register specified by the at least one register specifier, thereby allowing the hypervisor to determine how many bits of the register to check.

[0018] For example, these registers may be used by a virtual processor to track the last seen value of a given memory address in the memory system, which may then be polled to determine if it has changed to a particular value indicating that the virtual processor may proceed to the next section of code. By returning an indication that the register stores the last seen value of the polled variable, the hypervisor may be able to check if the polled variable has changed since its last seen value, at which point it may be worthwhile to attempt to reschedule the previously executed virtual processor once again. Although the polled variable will still be the same as its last seen value, this indicates that it is highly likely that the trap condition is still satisfied, and therefore there is no point in rescheduling the virtual processor until the value of the polled variable has changed. Thus, in some embodiments, a conditional yield to a hypervisor instruction may be included in a sequence of code followed by a particular instruction that loads the value of the polled variable into a given destination register, and the conditional yield to the hypervisor instruction may then specify a register specifier for the destination register used to store the polled variable. It should be understood that this is just one exemplary use case for a conditional yield on a hypervisor instruction, and that the same instruction can also be used to convey other information to the hypervisor, where a register that stores information useful in determining whether a trap condition is met has its register specifier passed to the hypervisor as schedule hint information so that the hypervisor itself can read the value from that register.

[0019] In some embodiments, the scheduling hint information may include an indication of multiple register specifiers specified by the conditional yield hypervisor instruction. In some cases, multiple different values ​​made available to the hypervisor may be useful to evaluate whether a trap condition is still likely to be met for a previously executed virtual processor. For example, in some cases, polling of a variable in memory may be qualified by a mask value that specifies which portions of the variable should be checked. For example, a lock variable used to control access to a given resource in memory may include multiple fields, including a field that specifies the identity of the process that holds the lock, as well as a field that indicates whether the lock is currently set or cleared. The mask may be used to ensure that the polling only responds to changes in the field that indicates whether the lock is set or cleared. Therefore, it may be useful to make such a mask available to the hypervisor, which may be done by conveying a register specifier for a mask register in addition to the register specifier for the register that holds the last seen value of the polled variable. Again, this is just one use case; in general, conditional yields on hypervisor instructions have an encoding that allows any two or more register specifiers to be copied to locations accessible to the hypervisor execution mode (regardless of the contents of those registers provided by previous instructions).

[0020] The at least one storage element accessible to instructions executing in the hypervisor execution mode may be at least one register. In some cases, the register to which the scheduling hint information is written may be a register that is not accessible to other instructions executing in a less privileged execution mode than the hypervisor execution mode. This allows other virtual machines or applications executing on the processing system to gain insight into the capabilities of the virtual machine that trigger a yield to the hypervisor. This may be important in some implementations where security is a concern.

[0021] In one embodiment, the conditional yield to the hypervisor instruction may include a wait-for-event (WFE) instruction to instruct the processing circuitry to wait until one of one or more classes of events is indicated as having occurred. The processing circuitry may determine that at least one trap condition is not satisfied when one of the one or more classes of events is indicated as having occurred. The classes of events may include various actions such as the occurrence of an interrupt or exception, the occurrence of a debug interrupt, or other diagnostic events such as a breakpoint or watchpoint, or the detection of a memory access to a tracked address tracked by an exclusive monitor. In general, the processing circuitry may trap to the hypervisor in response to the WFE instruction if none of these events have occurred. If one of these events has occurred, the WFE instruction may not trap to the hypervisor, and the virtual processor may continue processing subsequent instructions.

[0022] This may be particularly useful when the class of events includes detection of a memory access to a tracked address tracked by an exclusive monitor. This may be useful to enable workloads that involve locks or queue structures to manage access to shared resources, as described above. In this approach, a given address to be tracked may be assigned to an exclusive monitor, which may then monitor memory accesses made by other processor cores or other threads. If a memory access to a tracked address is detected, then this may be signaled as an event. If a WFE instruction is received and the indication detects that one of the events (including a memory access to a tracked address) has occurred, the WFE instruction is not trapped to the hypervisor so that the virtual processor can continue to progress forward, since the tracked address may now be updated to a value that results in the trap condition not being satisfied. If the event that occurred was not an update of the memory location corresponding to the tracked address to a value required to avoid trapping, a subsequent attempt to execute the WFE instruction may then trap once more. With this approach, the WFE instruction can be effectively used for conditional yield control of the processor to the hypervisor when an event wait has not yet occurred. In the above-described approach, such a WFE instruction may also be extended to return at least one scheduling hint information to enable the hypervisor to deduce whether the trap condition is still met.

[0023] For example, at least one item of scheduling hint information may include a hint address corresponding to a tracked address being tracked by the exclusive monitor at the time of execution of the WFE instruction. This hint address may be recorded in addition to a register specifier for one or more registers specified by the conditional yield hypervisor instruction described above. Recording the hint address allows the hypervisor to check a data value associated with the hint address itself to determine whether the value of the hint address has changed, which may then be factored into the scheduling decision. If the data value at the hint address has not changed from its previously seen value, it may be determined by the hypervisor not to reschedule the same virtual processor again.

[0024] Some systems may use two-stage address translation, in which an address translation circuit is provided that translates a virtual address specified by an instruction executed by the processing circuit into a physical address that identifies a memory location corresponding to the virtual address based on first address translation data indicating a mapping between the virtual address and an intermediate address and second address translation data indicating a mapping between the intermediate address and a physical address. Such two-stage address translation may be useful in a virtualized system because the first address translation data may be set by the virtual machine software and the second address translation data may be set by the hypervisor, allowing each virtual machine to manage access to memory in the same manner as if it were the only operating system executing on the processing hardware, while the second address translation data may be used by the hypervisor to map conflicting intermediate addresses from different virtual machines to different physical addresses.

[0025] In such a two-stage address translation scheme, the tracking address described above may be a physical address. However, in response to a WFE instruction, the scheduling hint information may include a hint address that is returned as an intermediate address that corresponds to the tracking address. This may be useful because a hypervisor may typically be able to translate the intermediate address into a hypervisor virtual address of an existing mapping more efficiently than a physical address.

[0026] If the scheduling information is to include an intermediate address corresponding to the traced address, the scheduling hint information may also include a valid indication that is set depending on whether the intermediate address corresponding to the traced address is available when switching to the hypervisor execution mode in response to the WFE instruction. In some cases, when executing the WFE instruction, the intermediate address corresponding to the traced address may not be cached in a translation lookaside buffer or other address translation cache, so obtaining the intermediate address may take time while page table structures that provide the mapping between the virtual address and the intermediate address are walked through to identify the intermediate address. If the intermediate address is not available but the trap condition is met to allow trapping to the hypervisor execution mode, it may be more efficient to trap to the hypervisor execution mode anyway, even if complete scheduling hint information including the intermediate address cannot be made available to the hypervisor. This is because trapping to the hypervisor execution mode provides an opportunity for the hypervisor to reschedule a different virtual processor, which would not be possible if trapping to the hypervisor execution mode was postponed until the intermediate address was available. Even if lack of knowledge of the intermediate address results in the hypervisor immediately rescheduling the same virtual processor that was previously trapped, this is simply the same delay penalty as if trapping had been postponed anyway while waiting for the intermediate address. Thus, trapping when the intermediate address is not yet available can improve performance by giving an opportunity to another virtual processor that is more likely to make forward progress than the previously yielding virtual processor, whereas when the intermediate address is available, having this available in the scheduling hint information can enable a more informed decision by the hypervisor to schedule which virtual processor to next schedule.

[0027] In some architectures, the setting of the exclusive monitor may occur in response to a load exclusive instruction that specifies a target address, where the instruction decoder controls processing circuitry to trigger the loading of a data value stored at the target address into a particular destination register and also triggers the exclusive monitor to set the target address as a tracking address.

[0028] In systems using two-stage address translation as described above, the address translation circuitry may have a translation cache for caching a portion of the address mapping between the virtual address, the intermediate address, and / or the physical address. Some approaches may use a split translation cache, where a first address translation cache is provided for caching entries of first address translation data that provide the mapping between the virtual address and the intermediate address, and a second separate translation cache is provided for caching a portion of the second address translation data that provides the mapping between the intermediate address and the physical address.

[0029] However, other implementations may bypass the intermediate addresses using a combined translation cache having cache entries for storing direct mappings from virtual addresses to physical addresses. Thus, when such a combined translation cache is updated, the information specified in the updated entries depends on both the first address translation data that controls the mapping between the virtual addresses and the intermediate addresses and the second address translation data that controls the mapping between the intermediate addresses and the physical addresses.

[0030] In a system using a split translation cache approach, when a WFE instruction is received following a previous execution of a load exclusive instruction directed to a given target address that is being tracked by an exclusive monitor, it is more likely that the intermediate address corresponding to the tracked address may still be cached in the first address translation cache of the split translation cache.

[0031] However, in a system using a combined translation cache, the cache entries of the combined translation cache directly store the virtual-to-physical address mapping, so that the intermediate address may be less likely to be available for inclusion in the scheduling hint information. Thus, in such a system, it may be useful for a load exclusive instruction to trigger a first address translation data lookup to obtain an intermediate address corresponding to the target address of the load exclusive instruction, even if the combined translation cache already includes a cache entry that stores a virtual-to-physical address mapping corresponding to the target address of the load exclusive instruction. For example, the address translation circuit may have a small amount of additional cache storage in this manner to cache multiple intermediate addresses corresponding to the target address of the load exclusive instruction. Such intermediate addresses are not required to service the load exclusive instruction itself if the required virtual-to-physical address mapping is already available in the address translation cache, and triggering an additional intermediate address lookup may be useful because it means that when a subsequent WFE instruction is executed, the intermediate address corresponding to the tracking address is more likely to be available to address the translation circuit, and therefore the intermediate address is more likely to be returned as scheduling hint information as described above. Thus, in a microarchitecture implementation using a combined translation cache, regardless of whether a direct virtual-to-physical address mapping for a load-exclusive instruction is already available, triggering an intermediate address lookup increases the likelihood of receiving an intermediate address as part of the scheduling hint information, thereby improving hypervisor performance by allowing more appropriate decisions to be made for scheduling virtual processors.

[0032] Nevertheless, it should be understood that the specific examples of the conditional yield to hypervisor instructions and the WFE instruction can also be used in microarchitectures that use separate address translation caches dedicated to first-stage and second-stage address mapping, respectively.

[0033] In some embodiments, at least one item of the scheduling hint information may include a valid indication that is set depending on whether the exclusive monitor tracked any addresses as tracked addresses at the time of execution of the wait for event instruction. This indication may be the same as the valid indication indicating whether the intermediate address is available as described above, or may be a separate indication. Returning an invalid indication if the address was not tracked by the exclusive monitor may flag the hypervisor that the hint address should not be considered when determining whether to reschedule the virtual processor. For example, sometimes the WFE instruction may be used for purposes other than handling polling of addresses in memory, so it may not always be desirable to make addresses tracked by the exclusive monitor available to the hypervisor, and thus a valid indication may be useful to qualify whether storage bits corresponding to addresses tracked by the exclusive monitor should be checked by the hypervisor when making its scheduling decisions.

[0034] In some cases, whether at least one trap condition is satisfied for a conditional yield to a hypervisor instruction may depend on a trap control indicator stored in a hypervisor control register that indicates whether the conditional yield to the hypervisor instruction should be tracked to the hypervisor. Thus, in some cases, there may be multiple forms of trap conditions that each must be satisfied, and the entire set of trap conditions may be satisfied if, for example, both of the trap control indicators indicate that a conditional yield to a hypervisor instruction should trap, and the processing circuitry determines, in response to a WFE instruction, that none of the one or more classes of events are indicated as occurring.

[0035] The ability to disable a trap to the hypervisor in response to a conditional yield on a hypervisor instruction that uses a hypervisor control register can be useful because a virtual processor may be the only virtual processor running on a given physical platform, in which case it may be more efficient to conditionally yield on a hypervisor instruction that is not a trap, and instead continue processing within the virtual processor itself without a trap, because there are no other virtual processors that can use the processing resources provided to the hardware, even if the event the virtual processor is waiting for has not yet occurred.

[0036] More specifically, the hypervisor control register may store a trap control indicator having one of a first value and a second value. In the example WFE instruction described above, when the trap control indicator has the first value, the processing circuit may determine that the at least one trap condition is not satisfied regardless of whether any of the classes of events are indicated as having occurred. When the trap control indicator has the second value, the processing circuit may determine whether the at least one trap condition is satisfied based on whether any of the one or more events of the required classes have occurred. Thus, when the trap control indicator has the second value, if none of the classes of events are indicated as having occurred, the at least one trap condition is considered satisfied, whereas if one of the one or more classes of events is indicated as having occurred, the at least one trap condition is not satisfied.

[0037] FIG. 1 illustrates generally an example of a data processing system 2 including multiple processor cores 4. In this embodiment, the system is a multiprocessor system having two processor cores, but in other embodiments, the system may have multiple processor cores or may only include a single processor core. When multiple processor cores 4 are provided, they may communicate with each other via an interconnect 6, which may manage coherency between caches 8 within each core. The processor cores 4 may share access to a shared memory system, which may include a shared cache 10 and a main memory 12. Each processor core 4 may include an instruction decoder 14 for decoding instructions fetched from an instruction cache or memory and for generating control signals for controlling processing circuitry 16 to perform data processing operations. Each core 4 may include registers 18 for storing operands processed by processing circuitry 16 and for storing control values ​​for controlling the operation of processing circuitry 16. Each core may also have a memory management unit (MMU) 20, which functions as an address translation circuit for translating between virtual and physical memory addresses, and an exclusive monitor 22 for tracking accesses to particular addresses by other parts of the system, both of which are described in more detail below.

[0038] 1, the general configuration of each of the processor cores 4 is shown as being the same, it should be understood that it is not necessary for each core to be identical, as there may still be microarchitectural differences between different cores within the same system. For example, one processor core 4 may have processing circuitry 16 that can have a greater instruction throughput than processing circuitry 16 in another core 4, or one core may have a larger cache capacity than another core.

[0039] As shown in Fig. 2, the processing system may have an architecture that supports virtualization, and multiple virtual machines may run on the same physical platform under the control of a hypervisor. Each virtual machine may manage the execution of a number of applications running under it in the same way as if the virtual machine was a native operating system that was the only operating system present, but the hypervisor may manage the scheduling of the different virtual machines and manage the mapping between the virtual resources (memory, peripherals, etc.) expected by the virtual machines onto the physical resources actually provided by the physical platform 2. The virtual machines may request that the hypervisor create resources to establish a given number of virtual processors (VPs), each of which emulates the presence of a given physical processor core, but if the virtual processors VPs are respectively mapped onto the physical cores of the physical platform provided in the hardware, a larger number of virtual processors may be provided than are actually provided in the hardware. Each virtual machine (along with the applications running under it) can request a particular number of virtual processors (e.g., VM0 can request the creation of virtual processors VP0-VP3, VM1 can request the creation of virtual processors VP4-VP5, etc.) and thus, while from the perspective of a given virtual machine it is running on a multi-processor core platform having a particular number of processor cores, these may actually be mapped onto a different number of physical cores in the hardware.

[0040] To support such virtualization, processor core 4 may operate according to a processor architecture that supports multiple execution modes of different privilege levels, labeled in the example of Figure 2 as EL2, EL1, and EL0. In this example, EL0 is the least privileged operating state and EL2 is the most privileged operating state. In some examples, there may be additional execution modes of even greater privilege than EL2, such as a secure monitor execution mode for executing secure monitor software that controls partitioning between a secure operating world and a less secure operating world.

[0041] In each execution mode, processing circuitry 16 may have access to a particular subset of the architectural state stored in registers 18. In general, any state accessible to a lower privilege mode may also be accessible to other modes of higher privilege than that mode. Thus, in EL1, instructions executed by processing circuitry 16 may have access to any register state accessible to EL0, but may also have access to some additional registers that are not accessible to the processor when operating at EL0. Similarly, when operating at EL2, the processor core may have access to certain registers that are not accessible to the processor when operating at one of EL0 and EL1. Transitions between different execution modes may be based on exceptions and exception returns, where an exception triggers a transition from a lower privilege state to a higher privilege state, and upon return from handling the exception, the processor processes back to the lower privilege execution mode. Exceptions may be caused by external events or by events caused by software executing in a given execution state, such as a memory fault or a conditional yield to a hypervisor instruction.

[0042] Figure 3 shows an example of a subset of registers 18 provided within processor core 4 according to a particular architecture. It should be understood that this is only a portion of the register state that may be provided, and that registers 18 may also include other architectural registers not shown in Figure 3, such as floating point registers for storing floating point values, or additional system registers for storing other control values.

[0043] As shown in FIG. 3, the registers 18 may include a set of general purpose registers 30 that are generally accessible to instructions executing in any of the execution modes. These may include a certain number of general purpose registers X0-X12, which may be available to instructions to use to identify operands for those instructions, or may be used as destination registers to which the results of instructions may be written. Some of the general purpose registers may serve special purposes for controlling the operation of the processor. For example, register X13 may function as a stack pointer register that provides an address of a corresponding stack data structure in memory that may be used, for example, to stack or unstack register states in response to exceptions and exception returns. Register X14 may function as a link register that stores a return address to which a process may return after processing another function. Register X15 may function as a program counter that indicates an address representing the current execution point.

[0044] The registers 18 may also include a number of system registers 32 that may store control values ​​used to control the operation of the processing circuitry 16. Figure 3 shows a subset of these registers, which may include a fault address register 34 for recording information about the address that triggered a memory fault, a pair of banked exception status registers 36, 38 for recording information about exceptions that may have occurred, and a hypervisor control register 40 for storing control information for controlling the operation of the hypervisor and which events trigger a trap to the hypervisor.

[0045] For example, this may occur if the currently executing process is not permitted to access a given region of memory to which access is requested, or if a corresponding virtual-to-physical address mapping for a registered address has not yet been defined. In response to a memory access that triggers a memory fault, the address that caused the fault is written to FAR34, so that when the fault triggers a trap to the virtual machine in EL1, or the hypervisor in EL2, the monitoring code can identify the reason for the fault from FAR32 and can then take action by allocating a new entry in the page table structures to allow the address to be mapped so that the fault does not occur again.

[0046] The exception status registers 36, 38 are banked such that if an exception occurs while executing at EL1, the register 36 (ESR_EL2) is used to make information about the cause of the exception available to the hypervisor executing at EL2 so that it can then take appropriate action. For example, an exception status identifier identifying the reason for the exception may be stored in the exception status register 36. Similarly, if an exception occurs while executing at EL0, information about the exception may be recorded in the exception status register 38 corresponding to EL1. By banking the exception status registers, this means that if a series of nested exceptions occur (an exception that triggers a switch from EL0 to EL1, followed by another exception from EL1 to EL2), then once the hypervisor returns to the virtual machine executing at EL1 after handling the exception at EL2, the virtual machine can further determine the reason for the exception that previously occurred at EL0 based on the contents of the second exception status register 38 (ESR_EL1).

[0047] The hypervisor control register 40 may include a number of bits that specify whether a number of different types of events may trigger the processing circuitry to switch to the hypervisor mode EL2. One of these events may be a trap control indicator 42 that controls whether a wait for event (WFE) instruction executing at one of EL0 and EL1 triggers a switch to the hypervisor execution mode EL2. It should be appreciated that the hypervisor configuration register (HCR) 40 may also include several other pieces of control information that affect the operation of the hypervisor or define circumstances that require the hypervisor to trap.

[0048] 3, the registers 18 may also include an event register 44 that is set when one of several specific classes of events occurs. The event register 44 may not be directly visible to software. Events that may cause the event register to be set may include a specific interrupt or exception, a specific debug event such as a breakpoint or watchpoint, or the detection of a memory access that attracts an address by the exclusive monitor 22 as discussed below.

[0049] As shown in FIG. 4, the MMU 20 in a given processor core 4 may manage address translation according to a two-stage address translation process. The virtual machine may define a stage 1 page table 50 that is stored in the memory system to define a mapping from a virtual address (VA) to an intermediate physical address (IPA). The virtual machine may be designed assuming that it is the only operating system running and assuming that the intermediate physical address is in fact a physical address that directly identifies a corresponding location in the memory system. However, the hypervisor may configure a stage 2 page table 52 that controls the mapping of the intermediate physical address to a physical address that actually identifies a corresponding location in the memory system. This allows the hypervisor to map IPAs used by different virtual machines to reference different variables in memory to different physical addresses to avoid conflicts.

[0050] As shown in FIG. 1, the MMU may include at least one address translation cache 21 (also known as a translation lookaside buffer or TLB) for caching portions of the page tables 50, 52 for faster access than if they had to be read from memory each time. In some systems, the TLB 21 may be a split TLB in which separate stage 1 and stage 2 TLBs are provided for caching portions of the stage 1 and stage 2 page tables 50, 52, respectively. However, other systems may use a unified TLB 21 in which each cache entry of the TLB stores a direct VA to TA mapping derived from a combination of entries read from the stage 1 and stage 2 page tables 50, 52. This allows a physical address to be located faster if it is already cached in the unified TLB for a given virtual address.

[0051] As shown in FIG. 1, a given processor core 4 has an exclusion monitor 22 that may be used to monitor accesses to particular addresses in memory. While FIG. 1 shows the exclusion monitor 22 provided within the processor core 4 itself, in other embodiments the exclusion monitor may be provided within the interconnect 6. Thus, in general, the core 4 has access to the exclusion monitor 22, which provides a structure within which addresses to be monitored may be registered. Once an address is registered within the exclusion monitor 22 as being tracked, the exclusion monitor hardware 22 may check the address of memory accesses made by other parts of the data processing system to detect whether the tracked address has been accessed. For example, the exclusion monitor 22 may intercept a snoop received from the interconnect 6 that is triggered by an access to memory by another processor core 4, and if the address indicated in the snoop request matches a tracked address recorded in the exclusion monitor 22, the exclusion monitor may signal an event, which may trigger the setting of an event register 44 shown in FIG. 3.

[0052] As shown in FIG. 5, setting of the address tracked by the exclusive monitor 22 may be performed in response to a load exclusive instruction decoded by the instruction decoder 14. In step 100, a load exclusive instruction is received. The load exclusive instruction may specify a destination register and one or more parameters for identifying a memory address #add, which may be a virtual address. For example, the address may be identified through a base register, and an offset or base register, and an immediate value, or any other addressing mode. In response to the load exclusive instruction, in step 102, the processing circuitry 16 triggers the exclusive monitor 22 to set the physical address corresponding to the virtual address #add as the tracked address to be monitored. If any other address has been previously tracked, it may be discarded, since in some embodiments there may only be space to track one address at a time. In step 104, in response to the load exclusive instruction, the processing circuitry 16 is also controlled to trigger the loading of a data value from an address in memory corresponding to the specified address #add into the destination register Xd.

[0053] 6 shows a flow diagram illustrating the tracking of memory accesses by the exclusion monitor 22. In step 110, the exclusion monitor 22 detects that a memory access to a given address is requested, for example by intercepting a snoop request triggered by that memory access request. In step 112, the exclusion monitor compares the address specified by the memory access with the registered tracked addresses being monitored to determine whether they are the same. If tracking is not continuing, the method returns to step 110 to detect the next memory access. If the address of the memory access matches the tracked address, an event is signaled in step 114 by updating the event register 44.

[0054] The use of a load exclusive instruction to set an exclusive monitor may be useful to enable a polling behavior in which a given virtual machine (or an application running under the virtual machine) may poll a variable in shared memory using a load exclusive instruction, followed by a wait for event (WFE) instruction that may indicate to processing circuitry 16 that no other action is required until an event is signaled. For example, such a virtual machine may include a polling loop as follows:

number

[0055] Thus, the first time the loop is executed, the WFE instruction detects that an event has occurred because it immediately follows the SEVL instruction, which is used to trigger a local event to ensure that the subsequent load exclusive instruction is executed at least once. The load exclusive instruction then reads the shared variable from memory, the AND instruction masks the return value based on the mask in register X2, and the conditional branch instruction CBNZ branches to the marker "loop" if the mask value is not zero. Thus, this is an example of a loop continuing to loop until the value of the variable in the shared memory is changed to zero, which may indicate, for example, that other processes now do not hold a lock that governs access to some associated data structure in memory. At this point, the virtual machine or virtual processor running the application can then proceed beyond the loop to the code that actually uses that data structure.

[0056] In a system where the virtual processor executing the virtual machine or application is the only virtual processor executing, the WFE instruction may simply cause the processing circuitry 16 to suspend execution until an event is signaled, at which time a check is made to see if a value in the shared memory has changed. However, in a virtualization system that simply allows the virtual processor to suspend, this may result in inefficiencies because while waiting for an event to be signaled, the hypervisor may reschedule another virtual processor, thereby allowing the previous virtual processor to perform some useful work in the processor time during which it is waiting for the event to occur. It may therefore be desirable to configure the WFE instruction to trap to the hypervisor if no event is pending. This may be done by setting the TWE flag 42 in the hypervisor configuration register 40 to indicate that the WFE instruction should trigger a trap to the hypervisor if none of the associated classes of events have occurred.

[0057] However, even if a WFE instruction triggers a trap to the hypervisor, the hypervisor then needs to determine which virtual processor to schedule next. For example, if virtual processor VP0 has just been trapped by a WFE instruction in a polling loop, as in the above example, the hypervisor would simply select VP0 again, and if the polled variables in memory have not changed, the virtual processor would simply not trap again, making forward progress and wasting processor time. It may be better for the hypervisor to select one of the other virtual processors VP1-VPn that can make forward progress. However, the hypervisor may have little visibility of the exact operations running in each virtual machine, and therefore cannot know whether a trap to the hypervisor was caused by a WFE instruction in a loop that polls a shared variable in memory. In some workloads that use a queuing mechanism to handle access to shared data in a particular order among multiple different virtual processors, this problem may be even more severe; for example, if virtual processors are in a queue in the order VP1, VP2, VP0, in order for any of the VPs to make forward progress using a shared variable, the hypervisor must select VP1 next because neither VP0 nor VP2 can make progress if they are behind VP1 in the queue. However, with existing techniques, it is difficult to gain access to information that allows the hypervisor to determine which virtual processors are likely to be held up due to access to a shared lock structure or queue. One approach may be paravirtualization, but such an approach suffers from the lack of portability and loss of performance discussed above.

[0058] As shown in Figure 7, in this application, a different approach is proposed in which the WFE instruction is extended to take a pair of register arguments Xa, Xb as source operands, but otherwise the trapping behavior is as described above for the WFE instruction. Thus, if the TWE bit 42 of the hypervisor control register 40 is set to an appropriate value, the WFE instruction triggers a trap to the hypervisor when the associated event is not signaled in the event register 44. However, when the WFE instruction traps to EL2, this triggers the return of scheduling hint information to the hypervisor, and is made accessible to the hypervisor within a portion of the system registers 32 accessible to the hypervisor. For example, the register numbers Xa, Xb specified by the WFE instruction, and an indication of the register width may be written to the exception status register 36 associated with the hypervisor execution mode EL2. Also, the failing address register 34 may be updated to indicate an intermediate physical address that corresponds to the physical address being tracked by the exclusive monitor 22 if the exclusive monitor 22 is currently tracking the tracked address and the intermediate physical address is available to the MMU 20 in its TLB 21, or, if the exclusive monitor 22 is not currently tracking any address and an intermediate physical address that corresponds to the tracked physical address is not available, the failing address register 34 may be set with an invalid indication that indicates that it does not represent an actual intermediate physical address. For example, this invalid indication may be an address value that does not correspond to an actual address in memory. For example, part of the address space may be reserved for special values ​​that do not correspond to actual memory locations, and the invalid indication may be one of those special values.

[0059] This new instruction allows a virtual machine or application to poll a variable in shared memory using a load exclusive instruction, followed by a new WFE instruction if the variable has not yet reached the desired value. If the variable is not being concurrently updated and therefore an event has not been generated, the new instruction traps to the hypervisor if the trap control in the hypervisor control register 40 is appropriately set. The virtual machine or application can use two register arguments Xa, Xb in the WFE instruction to communicate the last value of the shared variable observed, and an optional mask to specify which bits were being polled to the hypervisor.

[0060] For example, a modified version of the above code sequence is shown using the following new instructions:

number

[0061] Thus, when a WFE instruction traps, the hypervisor can obtain the intermediate physical address of the virtual address in X1 by reading the faulting address register 34, and then obtain its own virtual mapping for the same underlying physical page (e.g., based on a known offset between the existing mappings). With this mapping in place, determining whether to reschedule the same virtual processor can use code such as the following example:

number

[0062] Now, if the X0 resulting from the AND instruction is 0, the virtual processor will likely trap the next iteration of the polling loop since the bit being polled has not changed and should not be rescheduled. This approach does not suffer from the problems described above with paravirtualization and will work exactly without modification in a native environment where the WFE instruction was not trapped.

[0063] It should be understood that the particular software sequence above is just one exemplary use case for the WFE instruction described above. These registers do not need to indicate the last seen values ​​of the polled variables and masks as in the above example, since the same WFE instruction provided at the architectural level can be used in other ways by the software programmer, for example, to convey other scheduling hint information, such as those identified in registers Xa, Xb, to the hypervisor. Whether these registers provide the last seen values ​​and masks depends on which instructions have been executed prior to the WFE instruction, rather than being a required feature of the instruction set architecture supported by the instruction decoder 40.

[0064] In some embodiments, the scheduling hint information provided by the WFE instruction may be used when making a scheduling decision to select between virtual processors owned by the same virtual machine, but a scheduling decision for switching between a virtual processor owned by one virtual machine and a virtual processor owned by a different virtual machine may be independent of the scheduling hint information provided by the WFE instruction, since it is relatively unlikely that virtual processors of different virtual machines will share access to shared memory structures. In any case, it should be understood that software developers may find other uses for the scheduling hint information returned by the WFE instruction, and that the architectural features of the WFE instruction discussed below do not prescribe how this scheduling hint information is subsequently used.

[0065] The architectural features of the WFE instruction will now be described below with respect to FIG. 8. The WFE instruction is an example of a conditional yield to a hypervisor instruction that can switch to a hypervisor execution mode if a certain trap condition is met. In step 200, the instruction decoder 40 decodes the conditional yield to the hypervisor instruction, and the decoded instruction is passed to the processing circuitry 16 for execution. It should be understood that the execution of the instruction is pipelined so that the decoding of the instruction can take many cycles faster than the instruction being executed. In response to receiving the conditional yield to the decoded hypervisor instruction, in step 202, the processing circuitry 16 determines whether the current execution mode is the hypervisor mode or some higher privilege mode than the hypervisor mode, and if so, in step 204, the processing circuitry 16 can remain in the current execution mode. For example, a WFE instruction executed in the hypervisor execution mode EL2 may simply cause the processor to wait until an event is signaled, rather than any switch of execution mode.

[0066] If the current mode in which the conditional yield to the hypervisor instruction was executed is a less privileged execution mode than the hypervisor execution mode EL2 (e.g., the instruction is executed at EL0 or EL1), then in step 206 the processing circuitry determines whether any trap conditions required to trap to the hypervisor mode are satisfied. These are discussed in more detail with respect to Figure 9 below. If any trap conditions are not satisfied, again in step 204 the processing circuitry remains in the current execution mode.

[0067] If, in step 206, the required trap condition(s) are satisfied, in step 208, the processing circuitry can determine whether it is useful to switch to the hypervisor execution mode EL2, thereby rescheduling another virtual processor so that the hypervisor can step in and make forward progress of the previous virtual processor while waiting for the trap condition required by the previous virtual processor to no longer be satisfied. In step 210, upon switching to the hypervisor mode, the scheduling hint information is stored in at least one storage element accessible to instructions in the hypervisor mode. The storage of the scheduling hint information is shown in more detail in FIG. 10 below. By making the scheduling hint information accessible to the hypervisor at a structure level, the hardware automatically stores the hint information in certain registers or other storage elements accessible to the hypervisor without requiring explicit memory access instructions to package several messages using a shared data structure in memory to communicate between the virtual machine and the hypervisor, which improves performance and portability for the reasons described above.

[0068] 9 shows step 206 of determining in more detail whether the trap condition is satisfied. In step 220, the processing circuit determines whether the trap control indicator 42 (controlling whether the conditional yield for a hypervisor instruction (WFE) trap) is set to a first value or a second value. In this embodiment, the trap control indicator 42 has the first value when the corresponding bit of the hypervisor configuration register 40 is set to 0 and has the second value when the bit is set to 1, but in another embodiment it could be the other way around. Then, if the trap control indicator has the first value, in step 222, the trap condition is determined to be not satisfied, regardless of whether an event is signaled in the event register 44. Thus, when the trap control indicator is set to the first value, the WFE instruction is not trapped to the hypervisor. This can be useful, for example, to allow the hypervisor to disable tracking when it is currently only managing one virtual processor.

[0069] Then, if the trap control indicator has a second value at step 224, the processing circuitry determines whether the event register 44 is set to indicate that an event is being signaled. In particular, if the exclusive monitor 22 detects an access to the trace address, the event may be any of the classes of events described above, after which an event may be signaled. If an event is signaled, the method again proceeds to step 222, where it is determined that the trap condition is not met. On the other hand, if an event is not signaled, the method proceeds from step 224 to step 226, where it is determined that the required trap condition is met, in this case a switch to hypervisor mode at step 208 of FIG. 8, with a conditional yield to a WFE instruction or other type of hypervisor instruction.

[0070] FIG. 10 shows step 210 of FIG. 8 in more detail. In step 240, the processing circuit writes a register specifier and registers the width of the pair of registers Xa, Xb specified by the conditional yield to the hypervisor instruction in one of the system registers accessible to the hypervisor. In particular, this may be usefully written to the exception status register 36 corresponding to EL2. In step 242, the processing circuit 16 detects whether the exclusive monitor is currently cleared (not tracking any addresses), and if so, in step 244, an invalid indication is set in the fault address register 34. If the exclusive monitor is currently set, in step 246, it detects whether an intermediate physical address corresponding to the tracked physical address registered in the exclusive monitor 22 is available to the MMU 20 in its TLB 21, and if not, in step 244, an invalid indication is again set in the fault address register 34.

[0071] If the exclusive monitor is currently set and an intermediate physical address of the tracked physical address is currently available to the TLB 21, then in step 248, the intermediate physical address corresponding to the tracked physical address is written to the fault address register 34 and a valid indication is set. In some cases, the valid indication may simply be that the address in the fault address register is one of multiple invalid address values ​​that cannot correspond to an actual address. Alternatively, a separate valid bit may qualify the address in the fault address register. Similarly, in step 244, the invalid indication may either be a forbidden address value that cannot correspond to an actual address or may be indicated by a separate invalid indication. FIG. 10 shows an example in which the same invalid indication is used both when the exclusive monitor is currently clear and when the intermediate physical address is currently not available, and in other embodiments, two separate invalid indicators may distinguish between these two situations.

[0072] In a system in which TLB 21 of MMU 20 is implemented as a split TLB with separate stage 1 and stage 2 TLB structures, it may be relatively likely that the IPA corresponding to the tracked physical address will be available in TLB 21 at the time the WFE instruction is executed, because when a WFE instruction is used within a loop of the type shown here, it immediately follows a load exclusive instruction that causes the address mapping of that intermediate physical address to be loaded into the TLB (if it is not already in the TLB).

[0073] However, in an embodiment in which TLB 21 is implemented as a combined TLB that combines entries from stage 1 page table 50 and stage 2 page table 52 into a single unified entry that maps directly from virtual to physical addresses, then if a load exclusive instruction hits in an already allocated combined TLB entry, the load exclusive instruction typically does not trigger an address lookup in stage 1 page table 50 to obtain the intermediate physical address. However, if a load exclusive instruction is processed in this manner, this makes it less likely that the IPA corresponding to the tracked address will be available in step 246 when a subsequent WFE instruction is used.

[0074] Thus, in microarchitectures using a combined TLB, it may be useful to trigger a stage 1 table walk even if there is no need to service a load exclusive instruction. Thus, in the method of Figure 5, when a load exclusive instruction is received, if the target address does not already have an address mapping cached in the combined TLB 21, a page table walk is triggered to obtain an intermediate physical address from the stage 1 page table 50, and then to obtain the physical addresses that form the stage 2 page table 52, and further record the combined virtual address to the physical address mapping in the combined TLB 21. If a subsequent WFE instruction is required for scheduling hint information, the MMU 21 may also record the intermediate physical address in a specific storage area of ​​the MMU 20. Also, if a load exclusive instruction hits against an already allocated TLB entry and the intermediate physical address is not already available in MMU 21, even if the load exclusive instruction can be serviced based on the physical address already provided in the combined TLB, the load exclusive instruction may nevertheless trigger a stage 1 page table walk of stage 1 page table 50 to obtain the corresponding intermediate physical address, which may then be recorded for use by a conditional yield to a subsequent hypervisor instruction, even if the physical address is not directly needed to process the load exclusive instruction because it is already cached. Triggering an intermediate physical address lookup in response to a load exclusive instruction makes it more likely that the intermediate physical address will be available in step 246 of FIG. 10 when a WFE instruction is received. Thus, it is more likely that useful scheduling hint information can be provided to the hypervisor that can help improve the scheduling efficiency of the virtual processor when the hypervisor makes a scheduling decision.

[0075] It should be understood that triggering this additional IPA lookup is not a required part of the architecture, as whether it is necessary or not depends on the microarchitecture implementation. For example, in a system with a separate TL dedicated to stage 1 and stage 2 address translation, the additional IPA lookup may not be required. Also, even in systems that use a combined TLB, some microarchitectural designers may choose to reduce the implementation complexity of the load exclusive instruction and save power by avoiding triggering unnecessary IPA accesses (at the expense of less useful hypervisor scheduling hint information). Nevertheless, triggering such an IPA lookup can improve hypervisor performance in microarchitectures that wish to do so.

[0076] FIG. 11 illustrates a simulator implementation that may be used. While the previously described embodiments implement the invention in terms of apparatus and methods for operating specific processing hardware supporting the technology, it is also possible to provide an instruction execution environment according to the embodiments described herein that is implemented using a computer program. Such computer programs are often referred to as simulators insofar as they provide a software-based implementation of a hardware architecture. Types of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 330 that supports a simulator program 310 and optionally runs a host operating system 320. In some configurations, there may be multiple simulation layers between the hardware and the instruction execution environment provided, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but in certain situations, such an approach may be justified, such as when one wants to run code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional features not supported by the host processor hardware, or that are typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0077] While embodiments have been described above with reference to particular hardware configurations or functions, in the simulated embodiments, equivalent functionality may be provided by appropriate software configurations or functions. For example, particular circuits may be implemented as computer program logic in the simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented in the simulated embodiments as software data structures. In configurations in which one or more of the hardware elements referenced in the previously described embodiments reside on host hardware (e.g., host processor 330), some simulated embodiments may utilize the host hardware where appropriate.

[0078] The simulator program 310 may be stored in a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 300 (which may include applications, an operating system, and a hypervisor) that is the same as the application program interface of the hardware architecture being modeled by the simulator program 310. Thus, the program instructions of the target code 300, including the conditional yield to the hypervisor instruction described above, may be executed from within an instruction execution environment using the simulator program 310, thereby allowing a host computer 330 that does not actually have the hardware functions of the device 2 described above to emulate these functions. The simulator program 310 may include instruction decode program logic 312, an exclusion monitor program logic 316 and an address translation program logic 318 that correspond to the functions for the instruction decoder 14, the exclusion monitor 22 and MMU 20 described above, and program logic for managing a register emulation data structure 314 (stored in the memory of the host hardware 330) for emulating the architectural registers 18 of the device 2.

[0079] In this application, the term "configured to" is used to mean that an element of an apparatus has a configuration that can perform a defined operation. In this context, "configuration" refers to an arrangement or method of interconnection of hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that an apparatus element must be modified in any way to provide the defined operation.

[0080] Although exemplary embodiments of the present invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise embodiments, and various changes and modifications can be made by those skilled in the art without departing from the scope and spirit of the present invention as defined by the appended claims.

Claims

1. An apparatus comprising: a processing circuit for performing data processing; an instruction decoder for decoding instructions for controlling said processing circuitry to perform said data processing; Equipped with the processing circuitry has a hypervisor execution mode for execution of a hypervisor for managing one or more virtual processors executing on the processing circuitry, and at least one less privileged execution mode than the hypervisor execution mode, and when operating in the hypervisor execution mode, the processing circuitry has access to at least one register that is not accessible to the processing circuitry in the less privileged execution mode; In response to a conditional yield for a hypervisor instruction executed in the at least one less privileged execution mode, the instruction decoder controls the processing circuitry to: determining whether at least one trap condition is satisfied; Upon determining that the at least one trap condition is satisfied, switching the processing circuitry to the hypervisor execution mode; storing, in at least one storage element accessible to instructions executed in said hypervisor execution mode, at least one item of scheduling hint information for estimating whether said at least one trap condition is still satisfied; The apparatus is configured to:

2. 2. The apparatus of claim 1, wherein the scheduling hint information comprises an indication of at least one register specifier specified by a conditional yield for the hypervisor instruction.

3. 3. The apparatus of claim 2, wherein the scheduling hint information comprises an indication of a register width of at least one register specified by the at least one register specifier.

4. 4. The apparatus of claim 2 or 3, wherein the scheduling hint information comprises an indication of a number of register specifiers specified by a conditional yield for the hypervisor instruction.

5. the conditional yield to the hypervisor instruction includes an event wait instruction for instructing the processing circuit to wait until one of one or more classes of events is indicated as having occurred; 5. The apparatus of claim 1, wherein the processing circuitry is configured to determine that the at least one trap condition is not satisfied when one of the one or more classes of events is indicated as having occurred.

6. The apparatus of claim 5 , wherein the one or more classes of events include detection of a memory access to a tracked address tracked by an exclusive monitor.

7. 7. The apparatus of claim 6, wherein at least one item of said scheduling hint information comprises a hint address that corresponds to said tracked address being tracked by said exclusion monitor at the time of execution of said wait for event instruction.

8. an address translation circuit for translating a virtual address specified by an instruction executed by the processing circuit into a physical address identifying a memory location corresponding to the virtual address based on first address translation data indicating a mapping between the virtual address and an intermediate address and second address translation data indicating a mapping between the intermediate address and the physical address; 8. The apparatus of claim 7, wherein the trace address is a physical address, and the hint address is the intermediate address that corresponds to the trace address.

9. 9. The apparatus of claim 8, wherein the scheduling hint information comprises a valid set of instructions that depends on whether the intermediate address corresponding to the trace address is available upon switching to the hypervisor execution mode.

10. The apparatus of any one of claims 6 to 9, wherein in response to a load exclusive instruction specifying a target address, the instruction decoder is configured to control the processing circuitry to trigger the exclusive monitor to set the target address as the tracking address.

11. an address translation circuit for translating a virtual address specified by an instruction executed by the processing circuit into a physical address identifying a memory location corresponding to the virtual address based on first address translation data indicating a mapping between the virtual address and an intermediate address and second address translation data indicating a mapping between the intermediate address and the physical address; the address translation circuitry comprises a combined translation cache including a plurality of cache entries, each cache entry storing a virtual-to-physical address mapping; 11. The apparatus of claim 10, wherein in response to the load-exclusive instruction, the address translation circuitry is configured to trigger a lookup of the first address translation data to obtain the intermediate address corresponding to the target address, even if the combined translation cache already includes a cache entry that stores the virtual-to-physical address mapping corresponding to the target address of the load-exclusive instruction.

12. 12. The apparatus of claim 6, wherein at least one item of the scheduling hint information includes a valid indication that is set depending on whether the exclusion monitor tracked any address as the tracked address at the time of execution of the wait for event instruction.

13. a hypervisor control register for storing a trap control indicator indicating whether a conditional yield for the hypervisor instruction should trap to the hypervisor; 13. The apparatus of claim 1, wherein in response to a conditional yield for the hypervisor instruction, the processing circuitry is configured to determine whether the at least one trap condition is satisfied in response to the trap control indicator.

14. a hypervisor control register that stores a trap control indicator having one of a first value and a second value; when the trap control indicator has the first value, the processing circuitry is configured to determine that the at least one trap condition is not satisfied regardless of whether one of the one or more classes of events is indicated as having occurred; 13. The apparatus of claim 5, wherein when the trap control indicator has the second value, the processing circuitry is configured to determine that the at least one trap condition is satisfied when none of the one or more classes of events are indicated as occurring.

15. 1. A data processing method for an apparatus comprising a processing circuit having a hypervisor execution mode for execution of a hypervisor for managing one or more virtual processors executing on the processing circuit, and at least one less privileged execution mode than the hypervisor execution mode, wherein when operating in the hypervisor execution mode, the processing circuit has access to at least one register that is not accessible to the processing circuit in the less privileged execution mode, the method comprising: Decoding a conditional yield for a hypervisor instruction executed in the at least one less privileged execution mode; in response to decoding a conditional yield for the hypervisor instruction, determining whether at least one trap condition is satisfied; Upon determining that the at least one trap condition is satisfied, switching the processing circuitry to the hypervisor execution mode; storing, in at least one storage element accessible to instructions executed in said hypervisor execution mode, at least one item of scheduling hint information for estimating whether said at least one trap condition is still satisfied; A method comprising:

16. 1. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing instructions, the computer program comprising: instruction decode program logic for controlling said host data processing apparatus to decode instructions of a target code executed within said instruction execution environment to perform data processing corresponding to instructions of the target code, said instruction execution environment having a hypervisor execution mode for execution of a hypervisor for managing one or more virtual processors executing within said instruction execution environment, and at least one less privileged execution mode than said hypervisor execution mode, said instruction execution environment having access to at least one register not accessible to said instruction execution environment in said less privileged execution mode when operating in said hypervisor execution mode; In response to a conditional yield for a hypervisor instruction of the target code executing in the at least one less privileged execution mode, the instruction decode program logic controls the host data processing apparatus to: determining whether at least one trap condition is satisfied; Upon determining that the at least one trap condition is satisfied, switching the instruction execution environment to the hypervisor execution mode; storing, in at least one data structure accessible to instructions of the target code executing in the hypervisor execution mode, at least one item of scheduling hint information for estimating whether the at least one trap condition is still satisfied; The computer program product is configured to:

17. A storage medium storing the computer program according to claim 16.

Images