Means for forwarding a coordination request to a processing circuit in response to a configuration request

Abstract

The present invention describes an apparatus, method, and computer program. The apparatus includes a processing circuit configured to execute software and an interface configured to receive, from the processing circuit, a configuration request from first software requesting configuration of a virtualized device. In response to the configuration request, the interface is configured to forward a coordination request to the processing circuit, the coordination request including a request for second software having a higher privilege level than the first software to determine a response to the configuration request received from the first software.

Description

Background Art Technical Field

[0002] The present technology relates to the field of data processing systems. Technical Background

[0004] In a data processing system, dedicated hardware devices may be provided to perform specific tasks, and in some cases, there may be multiple users or multiple software applications sharing access to the same hardware device. Devices may be virtualized so that each user or software application believes they are the only one using the device, when in reality, the resources in the device are divided and shared among multiple users. Summary of the Invention

[0005] From an example, the present technology provides an apparatus comprising:

[0006] processing circuitry configured to execute software; and

[0007] an interface configured to receive, from the processing circuit, a configuration request from the first software requesting to configure the virtualized device;

[0008] wherein in response to the configuration request, the interface is configured to forward a coordination request to the processing circuitry; and

[0009] The coordination request includes a request for second software having a higher privilege level than the first software to determine a response to the configuration request received from the first software.

[0010] From another example, the present technology provides a method comprising:

[0011] executing software on the processing circuitry;

[0012] receiving, from the processing circuit, a configuration request from the first software requesting to configure the virtualized device;

[0013] forwarding a coordination request to the processing circuitry in response to the configuration request;

[0014] The coordination request includes a request for second software having a higher privilege level than the first software to determine a response to the configuration request received from the first software.

[0015] From another example, the present technology provides an apparatus comprising:

[0016] a device for executing the software;

[0017] means for receiving, from the means for executing software, a configuration request from first software requesting to configure a virtualized device;

[0018] forwarding a coordination request to the device for executing software in response to the configuration request;

[0019] The coordination request includes a request for second software having a higher privilege level than the first software to determine a response to the configuration request received from the first software.

[0020] From another example, the present technology provides a computer program for controlling a host data processing device to provide an instruction execution environment, the computer program comprising:

[0021] a processing logic component configured to execute the software; and

[0022] an interface program logic component configured to receive a configuration request requesting configuration of the virtualized device from first software executing on the processing program logic component;

[0023] wherein in response to the configuration request, the interface program logic component is configured to forward the coordination request to second software executing on the processing program logic component,

[0024] The second software has a higher permission level than the first software, and

[0025] The coordination request includes a request for the second software to determine a response to the configuration request received from the first software.

[0026] Additional examples, features, and advantages of the present technology will be apparent from the following description of examples read in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 An example of a hierarchy of authority levels in a data processing system is shown;

[0028] Figure 2 An example of a method for coordinating configuration requests is shown;

[0029] Figure 3 An alternative method of coordinating configuration requests according to examples of the present technology is shown;

[0030] Figure 4 shows an exemplary configuration of processing circuits and hardware devices;

[0031] Figure 5 An example of a data processing system is shown;

[0032] Figure 6 is a flow chart illustrating an example of a method of operation of a management interface;

[0033] Figure 7A and Figure 7B is a timing diagram illustrating an example of signals transmitted between components of a data processing system;

[0034] Figure 8 An example of a management interface is shown;

[0035] Figure 9 shows an example of a register used with a management interface;

[0036] Figure 10 is a flow chart illustrating an example of a method of operation of a management interface;

[0037] Figure 11 is a flow chart illustrating an example of a method of operation of a processing circuit;

[0038] Figure 12A and Figure 12B is a flow chart illustrating a method involving setting a coordination enabled state or a coordination disabled state;

[0039] Figures 13 to 15 An example of using a data processing system is shown; and

[0040] Figure 16 An example of a simulator implementation is shown. DETAILED DESCRIPTION

[0041] In a virtualization system, a virtualization device may receive instructions from multiple software applications being executed by a processing circuit, which is a circuit configured to perform processing operations corresponding to processing instructions (including processing instructions representing software applications). Multiple software applications may all be executed on the same processing circuit, or alternatively, they may alternatively be executed on different groups of processing circuits (for example, the processing circuit may include multiple processor cores in a multi-core system). Each software application has a privilege level that determines a specific set of permissions associated with the application and the degree of knowledge the application has about other software that can access the virtualization device. Therefore, a software application operating at a low privilege level may not be aware of other applications using the resources of the virtualization device when issuing instructions to the virtualization device. This increases the likelihood of conflicts between applications requesting to utilize the virtualization device.

[0042] To avoid conflicts, for some types of configuration commands used to configure virtualized devices, a higher-privilege application can coordinate requests sent to the virtualized device by a lower-privilege application. For example, if a lower-privilege application wishes to send a configuration request to the virtualized device, requesting that the virtualized device be configured according to the needs of the lower-privilege application, the higher-privilege program can coordinate the request to ensure that it is not allowed if the request could adversely affect other applications using the virtualized device. In some examples, such configuration requests are triggered by processing circuitry that executes dedicated instructions for triggering the configuration request. However, in other examples, the configuration request is triggered by processing circuitry that executes a load or store instruction that specifies a memory address mapped to the configuration request; for example, a write to a certain memory address can trigger the hardware to issue a configuration request to the virtualized device. Such requests and responses can be performed in an application-specific manner using writes to specific addresses or data structures in memory based on a pre-agreed protocol for interaction between the lower-privilege software and the higher-privilege software.

[0043] One way to perform such coordination is for a first (less privileged) software to send a request to a second (more privileged) software to coordinate the configuration request that the first software intends to send to the virtualized device. The second software can then return a response to the first software indicating whether the first software has permission to send the configuration request, and if so, the first software can issue its configuration request.

[0044] While this approach does have the beneficial effect of enabling coordination of configuration requests, it has the disadvantage that each software application requires specific drivers to enable it to communicate with other software applications (using application-specific protocols for interaction between applications that were known when the software was written) and has performance implications. Therefore, if the software application is ported to a different physical platform that is running a different operating system or other higher-privilege code, this may require a different protocol for requesting coordination from the higher-privilege code, thereby increasing the development cost for the software developer of the ported application. This approach also introduces costs for both the developer of the higher-privilege code and the developer of the lower-privilege code, as they both need to interact and agree on a protocol by which requests for coordination are sent from the lower-privilege code to the higher-privilege code, and corresponding responses are sent back from the higher-privilege code.

[0045] The present technology provides an alternative approach in which an interface (also referred to as a management interface in the examples described below) is provided in hardware between the processing circuitry and the virtualized device. The processing circuitry is configured to send a configuration request from the first software to the interface requesting configuration of the virtualized device. The interface receives the request and responds by forwarding a coordination request to the processing circuitry to request the second software (at a higher privilege level) to determine a response to the configuration request received from the first software. The coordination request may be simply a request for coordination of performing the configuration request, or it may include the configuration request itself, or it may include a modified version of the configuration request. In either case, the coordination request is a request that is subject to coordination to trigger the first software to determine a response to the configuration request.

[0046] Therefore, the first software and the second software do not communicate directly with each other, so they do not need pre-agreed specific drivers or specific protocols to achieve coordination. Each of the first software and the second software only needs to communicate with the interface according to the configuration command protocol defined by the architecture, and is therefore compatible with any other software that also uses the same command architecture supported by the interface hardware. Therefore, there is no need for direct collaboration between developers of higher-privilege code and lower-privilege code, or to update the lower-privilege code when porting to a different physical platform. In this way, from the perspective of the first software, which sends configuration requests to the interface and receives configuration responses, the coordination of configuration requests is performed transparently; the involvement of the second software is not highlighted to the first software.

[0047] In some examples of the present technology, after receiving the coordination request, the second software is configured to process the coordination request and send a coordination response related to the configuration request to the interface. The coordination response indicates the result of the coordination, such as whether the second software has determined to allow the configuration request, or an indication of the result of the software emulation function of the virtualized device. In response to receiving the coordination response, the interface is arranged to send a configuration response to the processing circuit based on the coordination response. Thus, the configuration response is a response to the configuration request from the first software.

[0048] Thus, coordination of configuration requests by the first (less privileged) software is performed via the interface, thereby avoiding the need for specific drivers for software applications to communicate directly with each other using memory access to shared data structures. This makes the system more versatile.

[0049] In some examples, based on the coordination response, the interface is configured to trigger the virtualized device to be configured as requested by the first software.

[0050] Furthermore, this also saves processing time by eliminating the need for the first software to first request coordination via higher-privilege software and then, if the coordination is successful, request configuration. Instead, the configuration request is sent directly to the interface, and if the coordination is successful, the configuration request can be executed without issuing a second request. Once the interface receives a configuration response from the processing circuitry, configuration of the virtualized device is allowed to be triggered based on the configuration request, as long as the coordination response indicates that the configuration request is allowed.

[0051] The configuration response sent by the interface to the processing circuitry can take a variety of forms, depending in part on the coordination response from the second software. In some examples, if the coordination response indicates that the configuration request should be rejected, the configuration response sent to the first software includes an error indication. If an error indication is received from the hardware interface in response to the configuration request, the first software can instead rely on other forms of coordination, such as by directly interacting with higher-privilege software, or alternatively, can abandon the request to configure the device.

[0052] In other examples, the coordination response can provide a simulated response to a configuration request generated in software by the second software rather than a configuration request directly executed by the virtualized device. In this case, the configuration response sent to the first software can be the same as the coordination response provided by the second software. That is, the second software can determine the appropriate response to the configuration request, provide the generated response to the configuration request as the coordination response, and the coordination response is forwarded directly to the second software by the interface without calling any function at the virtualized device. This can be useful for handling certain configuration functions that may not be supported by a specific model of the virtualized device.

[0053] In some examples of the present technology, the processing circuitry limits issuance of the coordinated response to software applications at a certain threshold privilege level or higher.

[0054] This may mean that the processing circuitry ensures that the coordination request is specifically directed to software with a sufficiently high privilege level (for example, the coordination request may be made by triggering an exception that provides a service at a threshold privilege level, or by updating data in an email address that is accessible only to applications at the threshold privilege level or higher), or it may mean checking that the privilege level of the second software is sufficiently high before allowing any coordination responses to be issued (if these operations are performed while in a privilege state lower than the threshold privilege level, attempting to issue a coordination response may result in a failure or be ignored). If the privilege level of the second software is not high enough, the processing circuitry may send an error indication to the interface.

[0055] The advantage of this is that only software with sufficient knowledge of the other applications that have access to the virtualized device can perform the coordination.

[0056] In some cases, it may be more efficient to not coordinate any configuration requests. Therefore, in some examples, the interface can be set to one of multiple states. For example, these states may include a coordination-enabled state and a coordination-disabled state. In the coordination-enabled state, the interface responds to configuration requests by forwarding the corresponding request to the processing circuitry, as described above. On the other hand, in the coordination-disabled state, upon receiving a configuration request, the interface does not forward the coordination request to the processing circuitry. In other words, in the coordination-disabled state, forwarding of coordination requests is suppressed or omitted.

[0057] In some examples, the interface may accept configuration requests issued with the coordination disabled state set. This may be useful in scenarios where only one application / user has been configured to use the virtualized device. In this case, coordination may not be required, and any configuration requests issued by a single application / user may be accepted without risk of interfering with other applications / users. Alternatively, if the virtualized device itself has the ability to coordinate requests, the coordination disabled state may be set.

[0058] In some examples, in the event that the coordination disabled state is set, the interface is arranged to send an error indication to the processing circuitry in response to receiving a configuration request. This may be useful in systems that execute legacy code at a higher privilege level that was not written to be compatible with the architecture-defined coordination request / response commands. In such cases, by returning an error indication, the first software at the lower privilege level may be informed that coordination is not possible at that architectural level, and the first software may then rely on other methods of requesting coordination, such as, for example, interacting with the second software via a pre-agreed protocol based on a shared data structure in memory.

[0059] The coordination enabled state or the coordination disabled state may be identified in the interface in a variety of ways; in some examples, the interface includes a register that is used to classify the enable indicator to indicate whether the coordination enabled state or the coordination disabled state is set.

[0060] The enable indicator may take any form, but in some examples may be a single bit, e.g., a logic "1" value may indicate a coordination enabled state, while a logic "0" value may indicate a coordination disabled state, or vice versa. In any case, storing the enable indicator in a register in the interface is an efficient method for indicating coordination enabled / disabled state.

[0061] In some examples, setting the coordination enabled state or the coordination disabled state by the processing circuit can be achieved by the processing circuit sending a coordination configuration command to the interface.

[0062] The coordination configuration command instructs the interface to switch between a coordination-enabled state and a coordination-disabled state. This allows software executing on the processing circuit (e.g., a higher-privileged second software) to control whether coordination is enabled. For compatibility with legacy code, the default state (in the absence of any coordination configuration command) may be for the interface to be in the coordination-disabled state.

[0063] In some examples, where the interface includes a register for storing an enable indicator, the coordination configuration command triggers the interface to change the value of the enable indicator stored in the register.

[0064] For example, if a value of "1" indicates that coordination is enabled, the interface is configured to respond to coordination configuration commands by writing a "0" instead of a "1." This is an efficient and easy-to-implement method of setting the coordination state, requiring only a single command type capable of switching between coordination enabled / disabled states in either direction.

[0065] Alternatively, dedicated enable and disable commands may be defined for enabling and disabling coordination at the interface, respectively.

[0066] In some examples, the processing circuitry is configured to limit issuance of coordination configuration commands to software of a given privilege level or higher.

[0067] This improves the security of the system by ensuring that only software with a specific set of permissions can change the coordination state of the interface.

[0068] In some examples, a coordination enabled state or a coordination disabled state may be set separately for each of a plurality of different types of configuration commands. Then, in response to a given type of configuration command, the interface is configured to determine whether to forward the coordination request to the processing circuitry based on which of the coordination enabled state and the coordination disabled state is set for the given type of configuration command.

[0069] Ensuring that the coordination enable / disable state is only set for specific types of configuration commands avoids wasting power and processing time by rejecting configuration commands of types for which coordination may be enabled, thereby improving the overall efficiency of the system (and vice versa). This approach allows the coordination state to be more tailored to the specific system in which the apparatus is employed. For example, some configuration commands may relate to device-specific functionality that may be supported in some models of virtualized devices but may not be supported in other models of virtualized devices. Configuration commands relating to functionality that is directly supported in hardware in the virtualized device may be set to disable coordination, while configuration commands relating to functionality that is not supported in hardware in the virtualized device may enable coordination, such that the corresponding functionality may be emulated in software of a higher-privileged second software in response to a corresponding coordination request.

[0070] In some examples of the present technology, the configuration command is associated with a device context identification value indicating an associated device context including at least one parameter associated with the virtualized device when used by the first software.

[0071] In an apparatus of the present technology, there may be many software applications that utilize the same virtualized device, each of which has a different set of requirements. Therefore, each device has its own device context that specifies one or more parameters of the virtualized device and is associated with an identification value. It is useful for the interface to know the source of the configuration requests it receives, for example, to allow a second software or interface to manage quality of service standards that manage fair sharing of resources in the device between competing applications attempting to use the virtualized device. Additionally, in some examples, certain requests from certain software applications may not need to be coordinated, so it is helpful for the interface to be able to identify when such a request has been received based on the identity of the first software. Providing a device context identification value can help achieve this.

[0072] There are many types of configuration requests that can be sent from the processing circuit to the interface, some examples of which are given. It should be understood that these are only some examples of the types of configuration commands to which the present technology can be applied, and there may be many other types that are equally applicable. One example is a request related to power management of resources of a virtualized device.

[0073] A software application at a lower privilege level (e.g., a first software) may not be aware of any other software using the resources of the virtualized device. This means that the first software may believe it is safe to instruct the device or a portion of the device to be powered down when the first software is no longer using the device. However, there may be other software applications that are also using the device that the first software is not aware of, so powering down the device or a portion of the device would be detrimental to the other software. Therefore, it is useful for higher privilege software (e.g., a second software) to coordinate such power management commands that are aware of all software utilizing the virtualized device. Therefore, it is beneficial to apply the present technology to configuration commands related to power management.

[0074] Another example of a type of configuration request to which this technique may apply is a request that is not supported in hardware.

[0075] Such a request may be a request to configure or use a resource that does not exist in the virtualized device, or a request to the virtualized device to perform an operation that the virtualized device does not actually support in hardware. In this case, software with higher authority (e.g., second software) may simulate the virtualized device's response to the configuration command. Therefore, the coordination request may also trigger the processing circuit to execute the second software to simulate the unsupported operation requested to be performed by the virtualized device. By providing an architecturally defined framework for configuration / coordination commands and responses, and a hardware interface for forwarding these commands between the first / second software, the software simulation may be made transparent to the first software, such that the first software believes that the configuration is performed by the virtualized device itself.

[0076] Another example of a type of configuration request to which this technique may apply is a request from an unallocated device context.

[0077] When the interface receives a configuration request from software with an unallocated device context, this can be coordinated to determine whether there are any resources to be allocated to the device context, or whether the unallocated device context needs to wait until resources are no longer in use by other device contexts. Therefore, the present technique is particularly beneficial in this case as well.

[0078] Virtualized devices may also take a variety of possible forms. These include hardware accelerators and input / output devices, but it will be appreciated that many other examples are possible.

[0079] A hardware accelerator is a specialized piece of computer hardware designed to perform a specific function more efficiently than would be possible in software running on a general-purpose CPU. Examples of hardware accelerators include graphics processing units (GPUs), artificial intelligence (AI) accelerators such as neural processing units (NPUs), or cryptographic accelerators. Hardware accelerators and input / output devices such as input ports, network interfaces, or any other type of input / output device can be shared by many software applications and are therefore particularly beneficial for applying this technology.

[0080] In some examples, the processing circuit is configured to send a device action trigger command from the first software to the interface, and the interface is configured to send the device action trigger command to the virtualized device, omitting sending a coordination request to the processing circuit in response to the device action trigger command.

[0081] Device action trigger commands are used to cause a virtualized device to perform a specific action, such as processing data. Once the virtualized device has been configured, these commands may not require coordination and can be sent directly to the virtualized device without coordination. This saves processing time by avoiding unnecessary coordination.

[0082] For example, where the virtualized device is a GPU or other hardware accelerator, a direct device action trigger command may be a request to process data by the hardware accelerator, while a configuration command may be a request to configure sharing of processing resources available to an application issuing the command, a request to change configuration settings of the accelerator, or a request to change a power mode of the accelerator, etc.

[0083] In some examples, the virtualized device may not support certain device action triggering commands. In this case, the interface can be configured to forward further coordination requests to the second software. The second software can then coordinate the device action triggering commands and also simulate the virtualized device to determine a response to the device action triggering commands.

[0084] This allows commands not supported in the hardware to be processed as if they were supported, thereby increasing the versatility of the system.

[0085] In some examples, the present technology includes a computer program for controlling a host data processing device to provide an instruction execution environment according to an apparatus described in any of the above examples. The computer program can be a simulator that includes handler logic and interface program logic to cause the host processing system to perform some functions of the processing circuit (execution software) and the interface (receiving configuration requests from the first software executed on the handler logic and forwarding coordination requests to the second software executed on the handler logic). When executed on the host data processing device, the simulator program can simulate the functions of these hardware components so that other applications executed above the simulator (designed to be executed on a hardware device having these components) can continue to operate in the same manner even when executed on a hardware platform that does not have some or all of these hardware components.

[0086] The present technology relates to a system in which multiple processes operate at different privilege levels. Before discussing the details of the technology, an overview of the concept of privilege levels is given by way of example.

[0087] Figure 1 An example of privilege levels (exception levels) for processes with access to virtualized devices is schematically shown. Operating at privilege level EL2 (exception level 2) is hypervisor 102. Hypervisor 102 can be implemented as a dedicated hardware component or as software, implemented as a series of instructions executed by processing circuitry. Hypervisor 102 manages the execution of virtual machines 104, thereby controlling their access to resources of the virtualized devices. Hypervisor 102 has the highest privilege level and is aware of and has access to all virtual machines 104 in execution, allowing it to coordinate any commands sent from a virtual machine 104 to the virtualized devices.

[0088] Virtual machines 104 operate at the next privilege level (EL1). Each virtual machine 104 is unaware of the operations of the other virtual machines because they all operate at the same exception level; this means that one of virtual machines 104 could inadvertently issue a configuration request to a virtualized device that would be detrimental to one or more of the other virtual machines 104. Therefore, it may be useful for some configuration requests from virtual machines 104 to be coordinated by hypervisor 102.

[0089] Multiple applications 106 execute within each virtual machine 104, with the applications 106 executing at the lowest privilege level, EL0. Each virtual machine 104 has control over the applications 106 running within its guest operating system. For example, VM0 104a has control over the first two applications 106a and 106b shown, but has no control over the applications 106 running on other virtual machines 104.

[0090] Thus, each privilege level defines the level of control a process has over other processes running on the virtualized device, with processes executing at EL2 having control over processes executing at EL1 and EL0, and processes executing at EL1 having control over processes executing at EL0. Furthermore, each privilege level is associated with a specific set of access rights, with higher-privileged processes having greater access rights than lower-privileged processes. It should be understood that some architectures may define more than three privilege levels. For example, a secure monitor executing at privilege level EL3, which is higher than hypervisor privilege level EL2, may control transitions between secure and non-secure operating domains. It should be understood that this is merely one example of a possible hierarchy of privilege levels, and that other implementations may use a different set of privilege levels, but generally speaking, a processing system supports the execution of software processes with different privilege levels, where higher-privileged processes are authorized to perform actions or access data that are not permitted to lower-privileged processes.

[0091] Figure 2 Shown with such Figure 1 Examples of system 200 with multiple permission levels such as those shown. Figure 2In FIG, two software processes 202 and 204 have access to a virtualized device 206. The software 202 and 204 are executed on a processing circuit (not shown), which may be the same processing circuit that executes both software processes 202 and 204, or may be different sets of processing circuits. The virtualized device 206 is a hardware component capable of performing operations under the control of the software processes 202 and 204. For example, the virtualized device 206 may be an input / output device or a hardware accelerator configured to perform specific functions more efficiently than is possible in software running on a general-purpose CPU, such as a dedicated graphics processing unit (GPU), AI accelerator, or neural processing unit (NPU) for artificial intelligence applications, or a cryptographic accelerator for performing cryptographic operations.

[0092] Each of the software processes 202, 204 has an assigned privilege level, one of which is a higher privilege software 204 and the other is a lower privilege software 202. For example, the lower privilege software 202 may be a virtual machine 104, such as Figure 1 1 and the higher-privilege software 204 may be the hypervisor 102 or a specific set of instructions executed within the hypervisor 102. Each of the higher-privilege software and the lower-privilege software 202, 204 may wish to send a request to configure the virtualized device 206 to receive data processing instructions from the software. Because it has a lower privilege level, the configuration request from the lower-privilege software 202 needs to be coordinated by the higher-privilege software 204.

[0093] exist Figure 2 In the illustrated arrangement, coordination occurs through communication between lower-privilege software 202 and higher-privilege software 204. Lower-privilege software 202 sends a coordination request to higher-privilege software 204, and in response to the coordination request, higher-privilege software 204 determines whether the configuration request from lower-privilege software 202 should be allowed or denied based on its knowledge of any other software that has access to resources on virtualized device 206. Higher-privilege software 204 then returns a coordination response to lower-privilege software 202 indicating whether the configuration request was allowed; if so, lower-privilege software 202 sends the configuration request to virtualized device 206.

[0094] Configuration requests and responses as described above may, for example, involve writing data structures to memory according to some agreed-upon application-specific protocol. Such writing would require the software developers of both higher-privilege software 204 and lower-privilege software 202 to collaborate in a manner tailored to the specific application. Thus, if multiple lower-privilege software applications attempt to interact with the same device, the developers of higher-privilege software 204 may agree on different data structures and protocols for interacting with each lower-privilege software item.

[0095] like Figure 2 As shown, requiring coordination of configuration commands from lower-privilege software 202 has several advantages; for example, coordination reduces the likelihood of problems caused by resource contention on virtualized device 206 and improves the security of system 200. However, this particular approach also has significant disadvantages in terms of system efficiency and versatility. For example, one disadvantage is that each configuration request from lower-privilege software 202 must be coordinated before being sent to virtualized device 206. This increases the processing time it takes for the request to reach the virtualized device, thereby reducing the efficiency of system 200. Another disadvantage stems from the fact that the two software processes 202 and 204 must communicate directly in order to perform coordination. This requires each software process 202 and 204 to have specific drivers 203 and 205 to enable communication with the other software process. These software drivers 203 and 205 need to be updated or reinstalled each time a software process is replaced, which means that the versatility of system 200 is limited. This is particularly problematic in modern systems where multiple users may share access to a single server, with users switching from one server to another as pricing and other circumstances change. Therefore, it would be beneficial to improve the efficiency and versatility of system 200.

[0096] Figure 3 An example system 300 employing the present technology is shown. Figure 3 In the illustrated system, a management interface 302 is provided between the software 202, 204 and the virtualization device 206. In this arrangement, the lower-privilege software 202 is configured to send configuration requests to the management interface 302 without first requesting coordination from the higher-privilege software 204. The management interface 302 then assumes the responsibility of sending a coordination request regarding the configuration request to the higher-privilege software 204. Coordination of the configuration request is performed by the higher-privilege software 204, but a coordination response is returned to the management interface 302 rather than to the lower-privilege software 202. If the coordination response indicates that the configuration request will be accepted, the management interface 302 sends a configuration response indicating this to the lower-privilege software 202 and triggers the virtualization device 206 to configure according to the configuration request. On the other hand, if the coordination response indicates that the configuration request will be rejected, the management interface 302 sends a configuration response indicating this (e.g., in the form of an error indication) to the lower-privilege software 202.

[0097] In the above example, the coordination response indicates whether the configuration request can be accepted or rejected.

[0098] However, in other examples, the coordination response may include a simulated response to the configuration request, which may be sent to the interface 302 and then forwarded to the first software 202 without requiring action at the virtualization device 206. This may be useful, for example, in processing certain configuration actions that are not actually supported in hardware by the particular model of virtualization device.

[0099] Configuration requests and configuration responses, as well as coordination requests and coordination responses, can be defined architecturally, so that hardware devices that conform to a particular architecture guarantee that software designed according to the architecture will operate in a predictable manner. Therefore, higher-privilege software and lower-privilege software 204, 202 can be designed to use configuration requests and configuration responses, as well as coordination requests and coordination responses, in the manner described above, without the need to agree on a coordination protocol with other software (agreements on protocols are valid between each software provider and a hardware provider or standard individually, rather than between two software providers, which is more efficient for software development).

[0100] This is an example of transparent coordination of configuration requests, where the coordination of configuration requests is hidden from the lower-privilege software 202, such that from the perspective of the lower-privilege software 202, the configuration request is sent to the management interface 302 (the lower-privilege software 202 might even be programmed as if it were sending the configuration request directly to the virtualized device 206), and then a response is received from the management interface 302. Thus, the coordination is performed without any participation of the lower-privilege software 202 and without the lower-privilege software 202 being aware of the participation of the higher-privilege software 204.

[0101] In this arrangement, because the coordination request is sent by the management interface 302 rather than by the lower-privilege software 202, there is no need to provide a dedicated driver 203 within the lower-privilege software 202 for communicating with the higher-privilege software 204, nor is there a need to provide a dedicated driver 205 in the higher-privilege software 204 for communicating with the lower-privilege software 202. This increases the versatility of the system 300, allowing either software program 202, 204 to be replaced without having to update or reinstall the drivers 203, 205 in the other software. Furthermore, this arrangement enables the lower-privilege software 202 to send configuration requests directly to the management interface 302 without having to wait for the higher-privilege software 204 to first coordinate the request. Consequently, the processing time required to send configuration requests is reduced, thereby improving overall efficiency.

[0102] Figure 3 The arrangement shown may also have uses other than coordinating configuration requests. For example, although most device actions trigger commands (see Figures 13 to 15) need not be coordinated, but device action trigger commands not supported by the virtualized device 206 may be coordinated and executed according to the above-described techniques.

[0103] Furthermore, the above mechanism can be used not only for coordination of requests, but also for implementing any other communication between the first software and the second software. This allows any communication between software applications to take place without the need for dedicated drivers.

[0104] Figure 4 A more detailed example of a hardware system 400 to which the present technology may be applied is shown. Figure 4 , multiple examples of virtualized devices are shown, including a network interface 402, a cryptographic unit 404, and a graphics processing unit (GPU) 406. Each of the virtualized devices 402, 404, 406 is a Figure 3 4. The example of virtualized device 206 is shown and is accessible to one or more of multiple processing units 408, 410, and all processing units 408, 410 and virtualized devices 402, 404, 406 have access to shared memory 412. GPU 406 includes multiple components, including processing circuitry 414 for performing operations under the control of one or more software applications executing on processing units 408, 410. The processing circuitry has access to register sets 418 and cache 416 for storing data or instructions retrieved from memory 412. A management interface 420 is also provided within GPU 406. Management interface 420 performs operations related to Figure 3 404. The management interface 420 is configured to receive configuration requests from the processing units 408, 410 and to send coordination requests to the processing units 408, 410. In this example, the management interface 420 is shown as a component of the GPU 406, however, the management interface 420 may also be a separate component of the virtualized device, as shown by the management interfaces 422, 424 provided for each of the network interface 402 and the cryptographic unit 404. The management interface 420 also has access to the register set 418.

[0105] Each of the processing units 408, 410 includes processing circuitry 426, 428 configured to perform operations to process instructions. The instructions processed by the processing circuitry 426, 428 may represent one or more software applications, such as Figure 3 The software applications 202 , 204 depicted in FIG4 each have a set of privilege levels. The processing circuit 426 has access to register banks 430 , 432 and caches 434 , 436 configured to store data or instructions retrieved from the memory 412 .

[0106] When first software executing on processing circuitry 426 of one of the processing units 408 requests configuration of one of the virtualized devices (e.g., GPU 406), processing circuitry 426 is arranged to send the configuration request to management interface 420 associated with GPU 406. The management interface responds to the configuration request by forwarding the coordination request to processing circuitry executing second, higher-privilege software, which may be the same processing circuitry 426 executing the first software or a different processing circuitry 428. The processing circuitry 426, 428 receiving the coordination request is then configured to coordinate the configuration request and send a coordination response to management interface 420, which is arranged to send the configuration response to processing circuitry 426 executing the first software and, based on the configuration request, optionally trigger configuration of the GPU.

[0107] Figure 5 A generalized overview of a system 500 according to an example of the present technology is shown. The system includes a virtualization device 206 and a processing circuit 502 communicating via a management interface 302. First software 504 and second software 506 having different privilege levels are executed on the processing circuit 502. Figure 3 3. An example of lower-privilege software 202 and higher-privilege software 204 is shown. Second software 506 has a higher privilege level than first software 504, so when first software 504 sends a configuration request to management interface 302, a reconciliation request is sent from management interface 302 to second software 506. Management interface 302 receives a reconciliation response from second software 506 and sends an appropriate configuration response back to first software 504. If reconciliation indicates that the configuration request is allowed, management interface 302 also triggers virtualization device 206 to configure according to the configuration request.

[0108] In this example, first software 504 and second software 506 are shown as executing on the same processing circuitry 502; however, it should be understood that this is just one possible configuration and first software 504 and second software 506 may also execute on different sets of processing circuitry.

[0109] Figure 6 is an example of a method according to the present technology that is used by a management interface such as Figures 3 to 5 4. A flow chart of an example of a method 600 performed by the management interface 302, 420, 422, 424 as shown.

[0110] In a first step S602, the management interface is configured to receive a configuration request from a processing circuit 426, 428, 502 executing first software 202, 504. The configuration request is a request to configure a virtualized device associated with the management interface. In response to receiving the configuration request, the management interface then forwards a coordination request S604 to a processing circuit executing second software 204, 506. The coordination request is a request from the first software to coordinate the configuration request. Next, in response to sending the coordination request, the management interface is configured to receive a coordination response S606 from the second software indicating whether the configuration request is allowed. The management interface then sends S608 a configuration response to the processing circuit executing the first software indicating whether the configuration request is accepted. Finally, after determining S610 whether the configuration request is accepted, the process either ends without configuring the virtualized device S612 (if the configuration request is not accepted) or after triggering S614 configuration of the virtualized device according to the configuration request.

[0111] Figure 7A and Figure 7B is a timing diagram illustrating some of the signals passed between components of the systems 300, 400, 500 according to the present technology. Figure 7A , first a configuration request 702 is sent from the first software 704 to the interface 706. Then, a coordination request 708 is sent from the interface to the second software 710, after which a coordination response 712 is sent from the second software 710 to the interface 706. Then, a configuration response 714 is sent from the interface to the first software. This illustrates that the coordination of the configuration request by the second software 710 is invisible to the first software 704. Focusing on the signals sent and received by the first software, only the configuration response 714 received in response to the configuration request 702 is seen. Since there is no direct communication between the first software 704 and the second software 710, no dedicated driver or protocol is required for communicating with the second software. The first software 704 is Figure 3 and Figure 5 The example of lower privilege software 202, 504 shown, the second software 710 is Figure 3 and Figure 5 The example of higher privilege software 204, 502 shown, and interface 706 is Figures 3 to 5 Examples of management interfaces 302, 420, 422, 424 are shown.

[0112] at the same time, Figure 7B 1 shows signals transmitted between the processing circuit 720 executing the first software and the second software, the interface 706 and the virtualization device 722, wherein the processing circuit 720 is Figure 4 and Figure 5 The examples of processing circuits 426, 428, 502 shown, and virtualization device 722 are Figures 3 to 5 Examples of virtualized devices 206, 402, 404, 406 are shown. Figure 7B In FIG, a configuration request 702 is sent from processing circuit 720 to interface 706, which responds by sending a coordination request 708 to processing circuit 720, requesting that higher-authority software coordinate configuration request 702. Processing circuit 720 then sends a coordination response 712 to interface 706, which then returns a configuration response 714 to processing circuit 720. Simultaneously with sending configuration response 714 to processing circuit 720, interface 706 sends a configuration command 724 to virtualized device 722 based on configuration request 702, which triggers virtualized device 722 to configure according to configuration request 702. It should be noted that although configuration command 724 and configuration response 714 are in Figure 7B , but they may also occur at slightly different times, as long as both do not occur before receiving the coordination response 712 from the interface.

[0113] In some examples of the present technology, a coordination-enabled state or a coordination-disabled state may be set. In the coordination-enabled state, coordination of configuration requests according to the technology described so far is facilitated; in the coordination-disabled state, coordination of configuration requests is not performed. This is useful in situations where the coordination result of a configuration request may always be the same; for example, if the first software is the only software accessing certain resources on the virtualized device, the configuration request may always be allowed. In contrast, if all resources are currently used by software with higher permissions than the first software, or if there is some failure, the configuration request may always be denied. In either case, there is no need to coordinate the configuration request because the result of the coordination is always the same; therefore, it is beneficial to switch to the coordination-disabled state to save processing time and power by avoiding unnecessary coordination from occurring. However, in other cases, coordination is still necessary, so the coordination-enabled state should be set.

[0114] The coordination enabled or disabled state can be set in the management interface in a variety of ways. Figure 8 An example of a management interface 802 including a register 804 is shown according to the present technology. Figures 3 to 5 、 Figure 7A and Figure 7B, 420, 422, 424, 706 in the example of the management interface 302, 420, 422, 424, 706 in FIG. Register 804 includes an entry storing an enable indicator that indicates whether the coordination enabled state or the coordination disabled state is set. The enable indicator may be in the form of a single bit (e.g., a logic "1" value may indicate a coordination enabled state, while a logic "0" value may indicate a coordination disabled state, or vice versa), or in any other form. The coordination enabled or disabled state is set by changing the enable indicator in the register, for example, in response to a coordination configuration command from the processing circuit.

[0115] Registers 804 may be provided within management interface 802, such as Figure 8 As shown, or the register may be a register group in a virtualized device (such as Figure 4 registers in register group 418 in GPU 406).

[0116] Figure 8 The illustrated management interface 802 also includes a determination logic component 806 configured to determine, in response to a configuration request from the processing circuitry executing the first software, whether to send a coordination request to the processing circuitry executing the second software based on the enable indicator set in the register 804 .

[0117] In some examples, the coordination enabled state or the coordination disabled state may be set individually for each of a plurality of different types of configuration commands, rather than setting the state for all configuration requests received by the management interface. Figure 9 An example of a register 902 in which this can be implemented is shown. Register 902 has eight entries 904, each for a different type of configuration request. Each entry stores an enable indicator that indicates whether a coordination-enabled state or a coordination-disabled state is set for the corresponding type of configuration request. In this example, each enable indicator is a single-bit value, where "1" indicates a coordination-enabled state for configuration requests of that type, and "0" indicates a coordination-disabled state for configuration requests of that type. For example, the enable indicators in entries 904b-d, 904f-g for configuration request types BD and FG are "1," thereby identifying that a coordination-enabled state is set for each of these types. This means that when the management interface receives a configuration request of one of those types, the coordination request is forwarded to the processing circuitry according to the example described above. On the other hand, the enable indicators in entries 904a, 904e, 904h for configuration request types A, E, and H are set to "0," thereby identifying that a coordination-disabled state is set for these types. This means that when the management interface receives a configuration request of one of those types, no coordination request is forwarded to the processing circuitry.

[0118] Although Figure 9The register 902 depicted in FIG. 1 shows only eight entries 904 for eight types of configuration requests, but it should be understood that any number of entries 904 may be included. The types of configuration requests involved may include, for example, configuration requests related to power management of resources on a virtualized device, configuration requests that are not supported in hardware, and configuration requests from unallocated device contexts. However, these are merely some examples of the types of configuration requests; other types of configuration requests are possible. Furthermore, register 902 is only a Figure 8 An example of register 804 is shown. Additionally, in some cases, multiple types of requests may share a single indicator 904 so that each of those types can be enabled / disabled simultaneously by setting the shared indicator, while other types may have separate enable / disable indicators 904.

[0119] Figure 10 is a flow chart illustrating an example of a method 1000 performed by a management interface according to an example of the present technology. The method begins at step S1002, which receives a configuration request of a given type from a processing circuit executing a first software. Next, for example, Figure 8 Determination logic 806 is shown making a determination ( S1004 ) as to whether coordination is enabled for a given type of configuration request. For example, this may involve determination logic 806 reading enable indicator 906 corresponding to that type of configuration request stored in entry 904 of register 902 . If coordination is determined to be disabled for the given type of configuration request, the method proceeds to step S1006 , which sends an error indication as a configuration response to the processing circuitry executing the first software. This indicates to the first software that the configuration request has been rejected. The first software may then rely on other means of making progress, such as by emulating the functionality of the virtualized device itself in software.

[0120] On the other hand, if it is determined that coordination is enabled for a given type of configuration request, the method moves to step S1008, which forwards the coordination request to a processing circuit executing a second software having a higher privilege level than the first software. In response to the coordination request, a coordination response is received S1010 from the processing circuit executing the second software, indicating whether the configuration request is accepted or rejected. A determination S1012 is then made, for example by the determination logic component 806, as to whether the coordination response indicates that the configuration request has been accepted. If it is determined that the configuration request has been rejected, an error indication is sent S1006 to the processing circuit executing the first software as a configuration response. On the other hand, if the configuration request is accepted, the method moves to step S1014, which sends an indication to the processing circuit executing the first software that the configuration request has been accepted, the indication forming a configuration request. Based on the configuration request, the interface then triggers S1016 configuration of the virtualized device.

[0121] Figure 11 An example of a method 1100 performed by a processing circuit according to an example of the present technology is shown. The method begins at step S1102, where a configuration request is sent from first software executing on the processing circuit to an interface. In response thereto, a coordination request is then received S1104 from the interface. The coordination request is then processed S1106 by second software executing on the processing circuit, the second software having a higher privilege level than the first software, and processing the coordination request by coordinating the configuration request. Once the coordination is complete, the method moves to a final step S1108 of sending a coordination response to the interface, the coordination response indicating whether the configuration request was accepted or rejected.

[0122] Figure 12A and Figure 12B is a flow chart illustrating a method involving setting a coordination enabled state or a coordination disabled state performed by a processing circuit and an interface, respectively.

[0123] Figure 12A It is shown that when it is determined S1202 that software of a given privilege level or higher is operating, the processing circuit sends S1204 a coordination configuration command to the interface. This is to ensure that the security of the system is maintained.

[0124] Figure 12B It is shown that when the interface receives S1206 the coordination configuration command, the enable indicator stored in the register changes S1208.

[0125] Figure 13 An example of the present technology is schematically shown. The figure shows one or more devices 1302, each capable of operating as a virtualized device under the control of a virtualization application 1304. The virtualization application 1304 (an example of the first lower-privilege software 202, 504, 704 described in the previous examples) has a CP (control path) driver 1306 and a DP (data path) driver 1310. The CP driver is configured to send control information such as configuration requests to the device 1302 via a virtualization device interface 1308, and the DP driver is configured to send commands (device action trigger commands) to the device 1302 to trigger specific processing operations to be performed on the device 1302.

[0126] When a configuration request is sent from the virtualized application 1304 via the CP driver 1306 to the virtualized device interface 1308, the interface 1308 responds by forwarding the coordination request to the privileged CP driver 1314 via the device interface 1312. The privileged CP driver 1314 returns a coordination response to the virtualized device interface 1308 via the device interface 1312, and the virtualized device interface 1308 then sends a corresponding configuration response to the virtualized application 1304 via the CP driver 1306. The virtualized device interface 1308 is an example of the management interface 302, 420, 422, 424, 706, 802 shown in the previous examples.

[0127] Device action trigger commands sent via the virtualized application's DP driver 1310 or by other DP drivers 1316 associated with device 1302 typically do not need to be coordinated and are therefore passed to device 1302 by virtualized device interface 1308 and device interface 1312, respectively. However, in some cases, they do need to be coordinated. For example, if the virtualized device's hardware does not support device action trigger commands, device interface 1312 can be configured to forward further coordination requests to second software executing on the processing circuit. The second software can then coordinate the device action trigger commands and also simulate the virtualized device's response to the device action trigger commands.

[0128] Figure 14 Examples of situations where the application of the present technology is particularly advantageous are shown. Specifically, Figure 14 The application of this technology to over-provisioning of device interfaces is shown.

[0129] exist Figure 14 In the virtualization device interface 1308 Figure 13 1304 and an additional virtualized application 1404. The additional virtualized application 1404 is arranged with a DP driver 1410 and a CP driver 1406 in the same manner as the first virtualized application 1304. In this example, the virtualized device interface 1308 is over-provisioned, which means that some of its resources have been allocated to both the first virtualized application 1304 and the second virtualized application 1404, both of which believe that they are the only applications with access to those resources. Traditionally, in this situation, when attempting to access the over-provisioned resources, memory accesses on both the control path 1402 and the data path 1408 would have to be trapped 1412. However, according to the present technology, memory accesses on the control path 1402 do not need to be trapped because they are transparently coordinated by the software or hardware responsible for managing the over-provisioned resources via the entitled CP driver 1314.

[0130] Another example of a situation where this technique is particularly beneficial is live migration, e.g. Figure 15 As shown in Figure 1 . When a virtualization application 1304 is live migrated from one host device 1302 to another host device 1502, the higher-privilege software pre-copies the allocated context from the first device 1302 to the second device 1502, while ensuring that the virtualization application 1304 does not make further changes to the configuration of the device 1302 without permission. Traditionally, this would require programming specific behavior into the virtualization application 1304 or the CP driver 1306, but the transparent coordination of configuration commands as described in accordance with the present technology means that this is no longer necessary.

[0131] Furthermore, the second device 1502 may not support the exact same feature set as the first device 1302, which would traditionally prevent live migration from successfully executing. On the other hand, this technology allows higher-privileged software to emulate the missing functionality of the second device 1502, thereby enabling live migration to execute on a wider range of systems. Therefore, this technology simultaneously improves system security and versatility.

[0132] Although Figure 14 and Figure 15 Specific examples of situations where application of the present technology is particularly beneficial have been shown in the accompanying drawings, but it should be understood that these are merely examples and that there may be many other situations where the present technology will provide advantages.

[0133] Figure 16A usable simulator implementation is shown. While the previously described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques involved, an instruction execution environment according to the embodiments described herein can also be provided that is implemented using a computer program. Such computer programs are often referred to as simulators, in part because 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 can run on a host processor 1630 that supports the simulator program 1610, which optionally runs a host operating system 1620. In some arrangements, multiple simulation layers can exist between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, a powerful processor was required to provide a simulator implementation that executed at a reasonable speed, but this approach may be reasonable in certain circumstances, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, a simulator implementation can provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or provide an instruction execution environment that is 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.

[0134] To the extent that embodiments have been previously described with reference to specific hardware constructs or features, in simulated embodiments, equivalent functionality may be provided by appropriate software constructs or features. For example, specific circuits may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or cache memory may be implemented as software data structures in simulated embodiments. Where one or more of the hardware elements referenced in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 1630), some simulated embodiments may utilize host hardware where appropriate.

[0135] The simulator program 1610 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to the target code 1600 (which may include an application program, an operating system, and a hypervisor) that is identical to the application program interface of the hardware architecture being modeled by the simulator program 1610. Therefore, the simulator program 1610 may be used to execute program instructions of the target code 1600 and commands initiated by those instructions, including the aforementioned configuration requests and responses, coordination requests and coordination responses, and device action triggering commands, from within the instruction execution environment, allowing the host computer 1630, which does not actually have the hardware features of the aforementioned apparatus 400, to simulate those features.

[0136] Specifically, the functionality of the above-mentioned interface can be simulated by the program logic component within the simulator program 1610. When the target code 1600 includes an instruction that will need to send a configuration request to the interface, the program logic component can be configured to simulate the functionality of the interface by forwarding the coordination request to a higher authority software, or by simulating the second software itself by coordinating the request itself. Therefore, configuration requests and responses, coordination requests and responses, and coordination processes can all be simulated within the simulator code 1610. Therefore, in some examples, the second software can actually be the simulator program 1610 itself. Other examples can still have a second software separate from the simulator program 1610.

[0137] In this application, the phrase "configured to..." is used to mean that elements of a device have a configuration that enables them to perform a defined operation. In this context, "configuration" refers to the arrangement or manner in which hardware or software are interconnected. For example, the device 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 mean that the device elements need to be modified in any way in order to provide the defined operation.

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

Claims

1. A host data processing device, comprising: a processing circuit configured to execute software, the software comprising first software and second software, wherein the second software has a higher privilege level than the first software; and a hardware-implemented interface configured to receive, from the processing circuit, a configuration request from the first software requesting to configure a virtualized device; wherein, in response to the configuration request, the hardware-implemented interface is configured to forward a coordination request to the processing circuitry for consideration by the second software; and The coordination request includes a request by the second software to determine a coordination response based on the configuration request received from the first software, the coordination response indicating to the hardware-implemented interface whether the virtualized device should allow or deny configuration of the virtualized device.

2. The host data processing device according to claim 1, wherein: The hardware-implemented interface is configured to receive the coordination response from the processing circuit in response to sending the coordination request; and The hardware-implemented interface is configured to send a configuration response to the processing circuitry based on the coordination response, the configuration response being a response to the configuration request.

3. The host data processing device according to claim 2, wherein: The hardware-implemented interface is configured to trigger the virtualized device to be configured based on the coordination response.

4. The host data processing device according to any one of claims 2 and 3, wherein: When the coordination response indicates that the configuration request from the first software should be rejected, the configuration response includes an error indication.

5. The host data processing device according to any one of claims 2 and 3, wherein: The processing circuitry is configured to limit issuance of the coordination response to a particular privilege level or higher.

6. The host data processing device according to any one of claims 1 to 3, wherein: When in the coordination-enabled state, the hardware-implemented interface is configured to forward the coordination request to the processing circuitry in response to the configuration request; and When in the coordination disabled state, the hardware-implemented interface is configured to refrain from forwarding the coordination request to the processing circuitry in response to the configuration request.

7. The host data processing device according to claim 6, wherein: In response to receiving the configuration request while in the coordination disabled state, the hardware implemented interface is configured to send an error indication to the processing circuitry.

8. The host data processing device according to claim 6, comprising: A register is configured to store an enable indicator indicating whether the coordination enabled state or the coordination disabled state is set.

9. The host data processing device according to claim 6, wherein: The processing circuit is configured to set the coordination enabled state or the coordination disabled state by sending a coordination configuration command to the hardware-implemented interface.

10. The host data processing device according to claim 9, comprising: a register configured to store an enable indicator indicating whether the coordination enabled state or the coordination disabled state is set; Wherein in response to the coordination configuration command, the hardware-implemented interface is configured to change a value of the enable indicator stored in the register.

11. The host data processing device according to claim 9, wherein: The processing circuitry is configured to limit issuance of the coordination configuration commands to software at a given privilege level or higher.

12. The host data processing device according to claim 6, wherein: The hardware-implemented interface is configured to set the coordination enabled state or the coordination disabled state respectively for at least two types of configuration commands; and In response to a given type of configuration command, the hardware-implemented interface is configured to determine whether to forward the coordination request to the processing circuitry based on which of the coordination enabled state and the coordination disabled state is set to correspond to the given type of configuration command.

13. The host data processing device according to claim 12, wherein: The configuration command is associated with a device context identification value indicating an associated device context, the associated device context including at least one parameter associated with the virtualized device when used by the first software.

14. The host data processing device according to any one of claims 1 to 3, wherein: The configuration request includes one of the following: requests related to power management of resources of the virtualized device; Requests not supported in hardware; and A request was made from an unallocated device context.

15. The host data processing device according to any one of claims 1 to 3, wherein: The processing circuit is configured to send a device action trigger command from the first software to the hardware-implemented interface; and The hardware-implemented interface is configured to, in response to the device action trigger command, send the device action trigger command to the virtualized device and omit sending a coordination request to the processing circuitry.

16. The host data processing device according to claim 15, wherein: When the virtualized device does not support the device action trigger command, the hardware-implemented interface is configured to forward a further coordination request to the processing circuitry in response to the device action trigger command; and The further coordination request includes a request that the second software emulate the virtualized device to determine a response to the device action trigger command.

17. A data processing method, comprising: executing software on a processing circuit, the software comprising first software and second software, wherein the second software has a higher privilege level than the first software; receiving, from the processing circuit at a hardware-implemented interface, a configuration request from the first software requesting configuration of a virtualized device; in response to the configuration request, forwarding a coordination request from the hardware-implemented interface to the processing circuitry for consideration by the second software; The coordination request includes a request for the second software to determine a coordination response based on the configuration request received from the first software, the coordination response indicating to the hardware-implemented interface whether the virtualization device should allow or deny configuration of the virtualization device.

18. A host data processing device, comprising: means for executing software, the software comprising first software and second software, wherein the second software has a higher privilege level than the first software; means for receiving, at a hardware-implemented interface from said means for executing software, a configuration request from said first software requesting configuration of a virtualized device; in response to the configuration request, forwarding a coordination request from the hardware-implemented interface to the means for executing software for consideration by the second software; The coordination request includes a request for the second software to determine a coordination response based on the configuration request received from the first software, the coordination response indicating to the hardware-implemented interface whether the virtualization device should allow or deny configuration of the virtualization device.

19. A computer program product comprising a computer program which, when executed by a host data processing apparatus, causes the host data processing apparatus to: executing software on a processing circuit, the software comprising first software and second software, wherein the second software has a higher privilege level than the first software; and receiving, from the first software at a hardware-implemented interface, an architecture-defined configuration request requesting configuration of a virtualized device; forwarding an architecture-defined coordination request from the hardware-implemented interface to the processing circuitry for consideration by the second software in response to the architecture-defined configuration request, The architecture-defined coordination request includes a request by the second software to determine a coordination response based on the architecture-defined configuration request received from the first software, the coordination response indicating to the hardware-implemented interface whether the virtualized device should allow or deny configuration of the virtualized device. 20 . A non-transitory computer-readable storage medium storing a computer program, which, when executed by a host data processing device, causes the host data processing device to perform the data processing method according to claim 17 .

Images