Identifier translation

Abstract

An apparatus in which memory management circuitry (figure 1, 60) provides memory management functionality to one or more input / output devices (figure 1, 40 & 50) in respect of a memory. Read circuitry

Description

The present technique relates to data processing. A data processing apparatus may have a memory management unit (MMU) for managing accesses to memory. For example the MMU may be responsible for translating virtual addresses specified by a device wishing to access memory into physical addresses which directly identify the locations to access in memory. The MMU may also control whether a device is allowed to access the requested address based on access permissions set for regions of the address space. A processing element capable of instruction execution, such as a central processing unit, may have its own MMU for managing access to memory in response to memory access transactions issued by the processing element. However, a processing system may also have input / output (I / O) devices which are provided with direct memory access to the memory system shared with one or more processing elements. Such I / O devices do not typically have their own MMU. Nevertheless, supporting address translation and other memory management functions, such as access permissions checking, for input / output memory access transactions (e.g. read / write transactions) issued by I / O devices can be helpful to avoid exposing physical memory directly to devices. This can be beneficial both for supporting virtual memory (allowing fragmentation of the memory used by a device across non-contiguous physical memory regions), and for security reasons (allowing access permissions checks to be imposed so that malicious devices cannot compromise data in memory not allocated for the device). Hence, it can be useful to provide an input / output memory management unit (I0MMU), also referred to as a system memory management unit (SMMU), which provides memory management functions including address translation for I / O memory access transactions originating from I / O devices. Viewed from a first example configuration, there is provided an apparatus comprising: memory management circuitry configured to provide memory management functionality to one or more input / output devices in respect of a memory; read circuitry configured to alter a behaviour of the memory management functionality provided to the one or more input / output devices in response to commands in one of a plurality of associated queues; and translation circuitry configured to translate one or more identifiers in the commands from virtual device identifiers to physical device identifiers that identify the input / output devices. Viewed from a second example configuration, there is provided a method comprising: providing memory management functionality to one or more input / output devices in respect of a memory; altering a behaviour of the memory management functionality provided to the one or more input / output devices in response to commands in one of a plurality of associated queues; and translating one or more identifiers in the commands from virtual device identifiers to physical device identifiers that identify the input / output devices. Viewed from a third example configuration, there is provided a computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program comprising: memory management program logic configured to provide memory management functionality to one or more input / output devices in respect of a memory; read program logic configured to alter a behaviour of the memory management functionality in response to commands in an associated queue; and translation program logic configured to translate one or more identifiers in the commands from virtual device identifiers to physical device identifiers that identify the input / output devices. The present technique will be described further, by way of example only, with reference to embodiments thereof as illustrated in the accompanying drawings, in which: Figure 1 schematically illustrates an example of a data processing system in which a number of input / output devices access memory through an input / output memory management unit (I0MMU); Figure 2 illustrates the use of a command queue; Figure 3 shows an example of the SMMU in accordance with some examples; Figure 4 illustrates the use of a stream table to provide a number of memory management parameters that can be used to control the memory management functionality with the present techniques; Figure 5 schematically illustrates an example of an SMMU in accordance with some examples; Figure 6 is of a flowchart that shows a method of processing in accordance with some examples; Figure 7 illustrates a simulator implementation that may be used; Figure 8 shows an example of configuration tables in memory; Figure 9 illustrates a first command (CMDCFGICIT) for causing invalidation in the configuration tables; Figure 10 illustrates a second command (CMDCFGISTTVSID) for causing invalidation in the configuration tables; Figure 11 illustrates a third command (CMD C^ which can be used to invalidate a complete STT for a specific qSID; Figure 12 schematically illustrates an example of an SMMU in accordance with some examples; Figure 13 is of a flowchart 1300 that shows a method of processing in accordance with some examples; and Figure 14 illustrates a simulator implementation that may be used. Before discussing the embodiments with reference to the accompanying figures, the following description of embodiments and associated advantages is provided. In accordance with one example configuration there is provided an apparatus comprising: memory management circuitry configured to provide memory management functionality to one or more input / output devices in respect of a memory; read circuitry configured to alter a behaviour of the memory management functionality provided to the one or more input / output devices in response to commands in one of a plurality of associated queues; and translation circuitry configured to translate one or more identifiers in the commands from virtual device identifiers to physical device identifiers that identify the input / output devices. Using the described technique it is possible for a command to be sent to the apparatus in which the input / output devices are addressed in a virtual manner. That is, the input / output devices have a physical identifier but may also be addressed using one or more virtual identifiers. The virtual identifiers may be used by execution environments such as guest operating systems or virtual machines. The translation circuitry provided in the apparatus provides translations between these virtual identifiers (as used in the commands) and physical identifiers. By enabling the input / output devices to be addressed in a virtual manner it is possible to give each execution environment a different view of the available input / output devices. This makes it possible to, for instance, hide some input / output devices from particular execution environments. For instance, if a particular input / output device should not be accessed by an execution environment then the hypervisor or other supervisor that manages the virtual spaces can simply not provide a virtual identifier for that device. In some examples, the apparatus comprises: a plurality of queue control storage circuits configured to indicate locations of the associated queues, wherein each of the plurality of queue control storage circuits is associable with one of a plurality of execution environments. Each of the queue control storage circuits can be associated with a different one of the plurality of execution environments. For instance, each such storage circuit can be associated with a guest operating system or supervisory software (such as a hypervisor). The assignment is such that commands can be provided by that execution environment that affects the memory management performed in relation to that execution environment. For instance, a guest operating system could request that translations held in relation to its memory domain (i.e. its intermediate physical address space or virtual address space) be invalidated. In some examples, the execution environments include one or more virtual machines and one or more hypervisors. A virtual machine is generally considered to be a non physical machine that runs on physical hardware. In this way, the same physical hardware may host a number of virtual machines. Each virtual machine may in turn be controlled by a ‘guest’ operating system. The virtual machines and / or the guest operating systems are then managed by supervisory software known as a hypervisor. The hypervisor may have the capability of creating new virtual machines, destroying virtual machines and ensuring that the virtual machines each operate in a ‘fair’ manner when competing for the same physical resources. In practice, each virtual machine / guest operating system may be given a view of a false physical environment rather than the real physical environment and the hypervisor can act as a go-between. For instance, the guest operating system may have a view of memory that excludes other guest operating systems. In other words, each guest operating system may lead to believe that it has a set of resources to itself. In practice, each time an access to the memory is made, a translation is performed that translates the guest operating system’s memory address to a real physical memory address known to the hypervisor. In some examples, the memory management functionality includes address translation for virtual addresses provided by the input / output devices to physical addresses used by the memory. As previously described, guest operating systems may use virtual memory in order to have their own individual view of memory. Similar functionality can be provided to input / output devices so that they each have their own view of the memory. In this situation, the apparatus provides memory management functionality so that virtual addresses provided by the input / output circuitry is translated to physical addresses that can be used to access the memory. In some examples, the memory management functionality includes address protection to control access to one or more restricted locations in the memory based on the input / output devices. The memory management functionality may include the ability to ‘protect’ access to certain parts of memory. That is, different input / output devices may be permitted to read, write, or read and write to particular addresses or locations within the memory. These restrictions can be enforced as part of the memory management functionality. In some examples, the translation circuitry is configured to translate the one or more identifiers in the commands using one or more configuration tables. The configuration tables may provide mappings from virtual identifiers to physical identifiers and thus be changeable at runtime by altering the tables. Meanwhile, the tables could be directly modifiable by a hypervisor or other supervisory software. The tables could be stored in a memory that is accessible to the apparatus or could be stored in the apparatus (provided suitable storage circuitry is available). In some examples, the one or more configuration tables define a virtual identifier translation space for each of one or more execution environments. A virtual identifier translation space provides a series of translations from virtual identifiers to physical identifiers. The virtual identifiers could be specific to a particular entity thereby defining a virtual identifier translation space. A different entity could use a different set of virtual identifiers to refer to the same physical identifiers in a different virtual identifier translation space. In some examples, the virtual identifier translation space for a given execution environment is configured to provide a translation for at least some of the input / output devices from a virtual identifier used by the execution environment to a physical identifier. In these examples, each virtual identifier space is associated with a particular execution environment. Each execution environment can therefore have its own (virtual) identifier to refer to a particular input / output device, which is not available for use by other execution environments. This allows, among other things, for particular input / output devices to be hidden to some execution environments, while being available for use by others. In some examples, the one or more identifiers comprise an execution environment identifier and a virtual identifier; the execution environment identifier is configured to identify the virtual identifier translation space for a given execution environment; and the virtual identifier is configured to identify a physical identifier for one of the input / output devices using the virtual identifier translation space. In these examples, a command can therefore include both an execution environment identifier that identifies a particular virtual identifier space and, within that space, a virtual identifier that can be translated into a physical identifier - the physical identifier identifying a particular input / output device. Varying the execution environment identifier provides a different virtual identifier space and providing a different virtual identifier provides a different physical identifier, which in turn points to a different input / output device. The combination of execution environment identifier and virtual identifier can therefore be used to provide a particular physical identifier and therefore a particular input / output device. In some examples, a size of the virtual identifier translation space is dynamically configurable. It may not be necessary for every execution environment to be able to issue commands to each input / output device. By being able to vary the size of the virtual identifier space (e.g. for each execution environment) it is possible to use the translation space efficiently. In some examples, the read circuitry is configured to respond to one of the commands being a virtual space invalidation command by invalidating the virtual identifier translation space belonging to the given execution environment specified in the virtual space invalidation command. Such a command may be issued in order to invalidate the virtual space identified by the execution environment identifier. So for instance, a particular CPU may have its virtual identifier translation space invalidated so that any virtual identifier to physical identifier translations that it has set up become invalidated and can no longer be used to communicate with the input / output devices. This might occur, for instance, if a guest operating system or virtual machine is destroyed - the identifiers that it used to refer to particular input / output devices should no longer be usable. In some examples, the read circuitry is configured to respond to one of commands being a translation invalidation command by invalidating a translation from the physical identifier to the one of the input / output devices in the virtual identifier translation space identified by the given execution environment specified in the translation invalidation command. The translation invalidation command makes it possible to invalidate a specific translation. For instance, the translation to address a particular input / output device by a particular execution environment This may be desirable if, for instance, access to the input / output device has been revoked for a particular execution environment or if the input / output device were to go offline so that it can no longer be addressed. In these cases, by removing the translation, it is no longer possible for that device to be accessed by that execution environment. In some examples, the read circuitry is configured to respond to one of commands being an execution environment translation invalidation command by invalidating each virtual identifier translation space belonging to the given execution environment specified in the execution environment translation invalidation command. A particular execution environment may have a number of translation spaces assigned to it. For instance, these virtual address spaces might be used for different applications running under a guest operating system or virtual machine, where each machine needs a different view of the input / output devices. In these situations, multiple address spaces may be provided. The particular command in this situation (the execution environment translation invalidation command) can be used to invalidate all virtual translation spaces belonging to a particular execution environment. In some examples, the apparatus is an I0MMU. An input / output memory management unit (I0MMU) is a device that acts as a memory protection unit for peripheral devices that can communicate with (e.g.) processors and memories connected via a bus. This might include monitors or other storage devices for instance. An I0MMU may also be referred to as an SMMU (system memory management unit). Being a memory management unit, the device is capable of memory management operations such as address translation and memory protection. The present technique could also be embodied as follows: In accordance with one example configuration there is provided an apparatus comprising: a plurality of queue control storage circuits, each configured to indicate a location of an associated queue; memory management circuitry configured to provide memory management functionality to one or more input / output devices in respect of a memory; read circuitry configured to alter a behaviour of the memory management functionality in response to commands in the associated queue; and translation circuitry configured to translate one or more addresses in the commands. The apparatus is configured to provide memory management functionality to one or more input / output devices. For instance, the apparatus may intermediate the one or more input / output devices and a shared memory on a bus so that requests to access the shared memory from the input / output devices pass through the apparatus. The read circuitry is provided so that software executing on, for instance, a CPU is able to configure the memory management. For example, the way in which the memory management is performed might be changed. As another example, if the apparatus has caching capability e.g. in the form of a Translation Lookaside Buffer (TLB) that caches virtual to physical address translations then such cache functionality might be invalidated or partially invalidated on request. In these examples, the commands that are received can be received from non-supervisor software (e.g. a non-hypervisor) executing on the CPU. As a consequence of this, the process of a guest operating system running on a virtual machine of the CPU issuing a command to the command queue can be made significantly more efficient. For instance, whereas this would ordinarily require a supervisor to provide a virtual command queue and a trap / response mechanism would have to be provided for the supervisor to detect a write to the virtual command queue, translate any provided addresses, and then copy the commands to the real command queue. It will be noted that since addresses are provided by a guest operating system, these addresses might be virtual addresses or intermediate physical addresses (since a guest operating system would generally not have access to the true physical addresses). Consequently, translation circuitry is provided as part of the apparatus to translate these addresses into a form usable by the apparatus. In some examples, the memory management functionality is provided in respect of a plurality of execution environments. A device can be assigned to a particular execution environment and hence the memory management functionality that is provided by the apparatus to the device is made in relation to that particular execution environment. For example, if the memory management functionality includes translation capability, the translation may be performed from the context of that given execution environment. The same translation request made in the context of a different execution environment (possibly by a different device) could lead to a different result. In some examples, each of the plurality of queue control storage circuits is associable with one of the plurality of execution environments. Each of the queue control storage circuits can be associated with a different one of the plurality of execution environments. For instance, each such storage circuit can be associated with a guest operating system or supervisory software (such as a hypervisor). The assignment is such that commands can be provided by that execution environment that affects the memory management performed in relation to that execution environment. For instance, a guest operating system could request that translations held in relation to its memory domain (i.e. its intermediate physical address space or virtual address space) be invalidated. In some examples, the execution environments include one or more virtual machines and one or more hypervisors. A virtual machine is generally considered to be a non physical machine that runs on physical hardware. In this way, the same physical hardware may host a number of virtual machines. Each virtual machine may in turn be controlled by a ‘guest’ operating system. The virtual machines and / or the guest operating systems are then managed by supervisory software known as a hypervisor. The hypervisor may have the capability of creating new virtual machines, destroying virtual machines and ensuring that the virtual machines each operate in a ‘fair’ manner when competing for the same physical resources. In practice, each virtual machine / guest operating system may be given a view of a false physical environment rather than the real physical environment and the hypervisor can act as a go-between. For instance, the guest operating system may have a view of memory that excludes other guest operating systems. In other words, each guest operating system may lead to believe that it has a set of resources to itself. In practice, each time an access to the memory is made, a translation is performed that translates the guest operating system’s memory address to a real physical memory address known to the hypervisor. In some examples, the memory management functionality includes address translation for virtual addresses provided by the input / output devices to physical addresses used by the memory. As previously described, guest operating systems may use virtual memory in order to have their own individual view of memory. Similar functionality can be provided to input / output devices so that they each have their own view of the memory. In this situation, the apparatus provides memory management functionality so that virtual addresses provided by the input / output circuitry is translated to physical addresses that can be used to access the memory. In some examples, each of the plurality of queue control storage circuits is dynamically associable with one of the plurality of execution environments at runtime. Thus in these examples, the execution environment to which the queue control storage circuit is associated can be changed and is not fixed. Such reconfiguration may be achieved by, for instance, a hypervisor or other supervisory software that supervises the guest operating systems / virtual machines. In some examples, the translation circuitry is the memory management circuitry. The apparatus provides memory management circuitry in order to provide memory management functionality to input / output devices. In these examples, the same memory management circuitry can be used to provide the translation services that are used to translate the one or more addresses provided as commands to the queue. In some examples, the memory management functionality includes address protection to control access to one or more restricted locations in the memory based on the input / output devices. The memory management functionality may include the ability to ‘protect’ access to certain parts of memory. That is, different input / output devices may be permitted to read, write, or read and write to particular addresses or locations within the memory. These restrictions can be enforced as part of the memory management functionality. In some examples, the apparatus comprises: a plurality of parameter storage circuits, each usable to obtain one or more memory management parameters for controlling the memory management functionality. The memory management functionality can thereby be controlled by setting particular parameters. The parameters are generally controlled via the hypervisor or supervisory software rather than the other execution environments. In some examples, the apparatus comprises: a plurality of parameter storage circuits, each configured to store a location of one or more memory management parameters for controlling the memory management functionality. In these examples, rather than storing the parameters themselves, the parameter storage circuits store an indication of a location where the parameters can be accessed. For instance, the parameters may be stored in memory and the parameter storage circuits may store a location in the memory at which the parameters are stored. In some examples, the memory management parameters comprise translation data for use with the translation circuitry. The translation tables may be used to indicate how an address provided by a particular execution environment can be translated into a physical address for use with the memory. The translation tables could be the same or a subset of the translation tables used with a guest operating system for that guest operating system to access memory. In some examples, the memory management parameters comprise a fault behaviour specifier; and in response to a memory fault, an action is taken in accordance with the fault behaviour. When performing address translation for an input / output device, it is possible that a memory fault will occur. This might occur in a number of situations such as if the input / output device is not permitted to access the requested memory location in the specified manner, or if the memory location is invalid (e.g. a negative address is provided, or an address past the range of addresses for that input / output device is provided). In these situations, an action can be provided that indicates what should occur. For instance, the action may specify that an exception be thrown at a particular CPU, or that the apparatus wait until a corrective action can be specified. In some examples, the memory fault could be ignored In some examples, the memory management parameters comprise an indication of an execution environment; and the memory management functionality is performed in respect of the execution environment. For example, when the input / output devices perform a memory access operation, they may specify a stream identifier (SID). The SID may be associated with one of the virtual machines or guest operating systems and thus see a view of memory that corresponds with the virtual machine or guest operating system. In some examples, the apparatus is an I0MMU. An input / output memory management unit (I0MMU) is a device that acts as a memory protection unit for peripheral devices that can communicate with (e.g.) processors and memories connected via a bus. This might include monitors or other storage devices for instance. An I0MMU may also be referred to as an SMMU (system memory management unit). Being a memory management unit, the device is capable of memory management operations such as address translation and memory protection. In some examples, the translation circuitry is configured to translate one or more addresses in the plurality of queue control storage circuits. In these examples, the virtual machine or guest operating system creates the ring buffer (e.g. via the hypervisor) and the location of this ring buffer is inserted into the queue control storage circuits. Since the address being inserted is based on the guest operating system’s view of memory, it is likely to be a virtual address which is then translated by the translation circuitry in order to access the ring buffer. In some examples, the memory management circuitry is configured to receive a device request for the memory management functionality from the one or more input / output devices, wherein the device request contains an input / output device identifier; and the translation circuitry is configured to translate one or more addresses in the command by issuing a queue request for the memory management functionality; and the queue request contains a queue identifier of the associated queue of one of the plurality of queue control storage circuits. Particular embodiments will now be described with reference to the figures. Figure 1 schematically illustrates an example of an system (e.g. a data processing system, integrated circuit or system on chip) having at least one processor 20. In this example the processor is a CPU (Central Processing Unit), but other examples of processors include a GPU (Graphics Processing Unit) or NPU (Neural Processing Unit - a type of processor with specialized hardware for accelerating vector and / or matrix operations or other operations used in Neural Network and other machine learning processing). While Figure 1 only shows one such processor, it will be appreciated that system could have two or more such devices, which may include further CPUs or could include other types of instruction execution devices such as a GPU or NPU. The processor 20 has a Memory Management Unit (MMU - not shown) which functions as address translation circuitry for translating virtual addresses specified by instructions executed by the processor 20 into physical addresses identifying locations within the memory system 30. The MMU may have at least one TLB for caching translation information, which depends on page table data from page table structures stored in the memory system 30. The page table structures define the address mappings between virtual and physical addresses and may also define memory access permissions which may define whether certain software processes executing on the processor are allowed to access certain addresses. In addition to the processor 20 or other devices capable of instruction execution which have their own internal MMU, the system may also include one or more devices 40, 50 which may not have an MMU. Such devices may communicate with the rest of the system via a System Memory Management Unit (SMMU) 60, which includes memory management circuitry, which aids in (for instance) performing memory address translation and memory protection functionality. This functionality may be performed based on data defined in structures in memory. The SMMU 60 may have one or more TLBs 62 of its own, which have a similar functionality to the TLB within the MMU of the processor 20. The devices 40, 50 that access memory via the SMMU 60 can include cached devices which include an internal cache and uncached devices which do not have any cache. For example, a device 40, 50 could include a display controller for controlling display of image frames on display, a network controller for controlling input or output of data via a network, a hardware accelerator for performing certain dedicated processing functions (e.g. cryptographic processing, or neural network processing) in a more efficient manner than can be achieved using software executing on a generic processor such as the processor 20, and so on (e.g. other types of I / O device other than a display controller or network controller). All of the units 20, 40, 50 communicate with each other via an interconnect 10 which is responsible for routing transactions between the requester devices and memory 30. Interconnect 10 may also be responsible for managing coherency between data cached in respective caches of the system. It will be appreciated that Figure 1 is a simplified diagram and the system may have many other components not shown in Figure 1 for conciseness. The TLB 62 stores recently or commonly used translations between virtual and physical memory addresses. So, as a first step in an address translation process, the TLB 62 is consulted to detect whether the TLB already contains the required address translation. If not, then a more involved translation process may be used, for example involving consulting so-called page tables holding address translation information, typically resulting in the TLB 62 then being populated with details of the required translation. Typically, a device 40, 50 will be operate in coordination with software executing on an execution environment (e.g. a virtual machine, guest operating system, or hypervisor) running on a processing unit 20. Since the view of the memory 30 may differ for each execution environment, the view of memory used by a device 40, 50 should match the execution environment with which the coordination is taking place. For instance, if a given guest operating system is coordinating with a device 40 then the guest operating system and device should share a view of memory. The memory management functionality provided by the SMMU 60 is therefore dependent on the context associated with a memory access request from the device 40. In one case, a memory access request might use one view of memory and in another case another memory access request might use a different view of memory. A memory access request provided by a device 40, 50 to the SMMU can therefore provide a stream ID to indicate the context in which a memory access request is being made. Each stream ID can then be associated with one or more execution environments. Figure 2 illustrates the use of a command queue, which can be used to control the behaviour (e.g. the memory management functionality) of the SMMU 60. In this example, the actual command queue itself is stored in memory, which allows for the command queue to be large. The command queue may be of a predefined length. In this example, the command queue is set to being 8 bytes and is implemented as a circular buffer. However, in other examples, different structures can be used. In other examples, the command queue could be stored within the SMMU rather than in memory. Where the command queue is stored in memory, the SMMU provides three registers. An SMMUECMDQBASE register 102 points to a location in memory where the command queue is stored. That is, the register points to, for instance, a first byte of the location in memory where the command queue is stored. Data is written to the command queue in memory by, for instance, a hypervisor or supervisory software that manages the physical hardware. Where only a single operating system exists, this might be the operating system itself. Regardless, as data is written into the queue, the value in the SMMUECMDQPROD register 104 is incremented to show that data has been produced. This value could be a raw counter, or count be a pointer to a part of the command queue that represents the end of the produced data (either the final byte, or the first empty byte). The SMMUECMDQCONS register 106 is incremented as data is read from the queue. For instance, the SMMU ECMDQ CONS register 106 may point to the end of the consumed data (either the final byte or the first unread byte). Figure 2 shows an example of writing to the command queue. In this example, the value in the SMMU ECMDQ BASE register 102 points to the (e.g. physical) address of the first byte in the command queue throughout the example. In a first state, the producer and consumer values are the same and this therefore indicates that the command queue is empty. Values A, B, C, D are then written to memory in the bytes following the value in the SMMUECMDQBASE register 102. The producer value is then incremented - in this case to point to the next empty bytes. When reading of the command queue occurs, the values A, B, C, D are consumed and the value of the SMMUECMDQCONS register 106 is incremented until it points to the same value of the SMMUECMDQPROD register 104. Note that the value of the SMMUECMDQCONS register 106 cannot overtake the value of the SMMUECMDQPROD register 104 register (although see below regarding wraparound of the command queue). Next, values E, F, G, H, I are written to the command queue. The writing of these bytes would cause the physical command queue to be exceeded and thus, wraparound occurs (replacing byte I which has been read). A production wrap bit is set (e.g. to ‘1’) to indicate that wraparound has occurred. Further bytes J, K, and L are written (overwriting bytes B, C, and D which have also been read). Note that with wraparound having occurred, the value of the SMMU ECMDQ PROD register 104 must not overtake the value of the SMMU ECMDQ CONS register 106 or data loss can occur. Thus, further writing cannot be performed until bytes have been consumed. Bytes E, F, G, H, and I are then consumed, with wraparound occurring. This time, a consumer wrap bit is set (e.g. to ‘ 1’) to indicate that wraparound of the consumer having occurred. Finally, bits J and K are consumed, bringing the values of the SMMU ECMDQ PROD register 104 and the SMMU ECMDQ CONS register 106 into alignment in an empty command queue. In this example, the wraparound bits alternate whenever wraparound occurs. In other examples, when wraparound bits are both set, then are both cleared. A difficulty with this mechanism is that it is reliant on the supervisor / hypervisor to write to memory and to update the registers. In particular, since there may be several pieces of software executing at the lower execution level, it is necessary to arbitrate between them. This can be achieved by providing a virtual command queue to each piece of software at the lower execution level (e.g. each guest operating system) and then having the hypervisor copy data to the real physical command queue. However, this process can be slow. The present technique provides direct access command queues to guests (e.g. virtual machines or guest operating systems) thereby improving the efficiency with which commands can be sent to command queues. Various forms of stream ID (SID) are used in the system. A pSID (physical stream identifier) refers to a device 40, 50. A vSID is a virtual form of the pSID and is specific to a guest operating system or virtual machine. For instance, a virtual machine might use the vSID 505 to refer to pSID 4. This technique also introduces the idea of a qSID, which is a SID attached to a particular command queue and can therefore be associated with a particular guest operating system or virtual machine. Figure 3 shows an example of the SMMU 60 in accordance with some examples. Each command queue is implemented using a ring buffer 202, which is provided in memory and operates in a manner similar to that already described. Each command queue has a set of BASE / PROD / CONS registers 204 which operate together with the ring buffer 202 as previously described. The BASE / PROD / CONS registers 204 (potentially together with other registers) collectively form what is known as a command queue control page. Two type of control pages are present: those accessible by privileged SW like the hypervisor (ECMDQ BASE / PROD / CONS) and those accessible by the guest (DCMDQ BASE / PROD / CONS). Registers are provided (such as the registers 206 / 208) that indicate where the control page registers can be found. Note that the size of the control pages (and indeed, the grouping of command queues into pages) is immaterial to the present invention. Access to both the command pages and the ring buffers is controlled via the Virtual Machine System Architecture (VMSA), e.g. using virtual addresses and so on to control access to the resources. In practice, a guest (e.g. a virtual machine or guest operating system) can directly access the ring buffer 202 for a particular queue and the associated control page registers (the BASE / CONS / PROD registers) for that ring buffer to directly send commands to that command queue. The guest then updates the PROD register for that command queue to indicate that new commands have been inserted into the ring buffer 202. Once this has been done, the SMMU 60 itself reads the commands and acts on them. As explained above, the commands affect the memory management functionality in respect of a particular context or environment - i.e. the context to which the queue is assigned. Finally, the SMMU 60 updates the CONS register to represent the fact that the commands have been consumed. Thus, the changing of the SMMU memory management functionality can be achieved without relying on a hypervisor / supervisor. Whether or not a command queue is intended to be directly accessible by a guest operating system or virtual machine can be controlled by a SMMUECMDQBASE.DM flag 108 in the SMMU F.CMDQ BASF, register 108. For instance, a £ 1’ might indicate that direct mode is enabled and a ‘0’ might mean that direct mode is disabled (so that only the hypervisor or other supervisory software can access that particular command queue). In practice, access control is achieved by the VMSA since the hypervisor can prevent a guest from accessing the DMCMDQ control page (or ring buffer) if the command queue is not in direct mode or is assigned to another guest. This flag also makes it possible for the SMMU to reject certain privileged commands from being executed when the command queue is directly accessible by a guest operating system (e.g. in direct mode) rather than under the control of the hypervisor. The values of the registers in the control pages can be maintained in at least two different ways. In a first way, the physical memory addresses of the ring buffers 202 are stored in the BASE registers 102. Thus, the SMMU knows where the ring buffers 202 can be found and reads to those memory locations can be made. When the guest operating system or virtual machine attempts to access the BASE registers 102, the returned values can be intercepted (e.g. by the SMMU 60) and replaced with the virtual addresses that would be known to the guest operating system / virtual machine - assuming that guest operating system / virtual machine has permission to access the BASE register 102. In a second way, the virtual addresses used by the guest operating system / virtual machine are inserted into the BASE registers 102. These addresses are then translated by the SMMU 60. By providing translation in this manner, it is possible for the physical location of the ring buffers 202 to change, e.g. as the ring buffer is expanded, contracted and so on. Figure 4 illustrates the use of a stream table 310 to provide a number of memory management parameters that can be used to control the memory management functionality with the present techniques. In this example, the stream table 310 is provided in memory. The SMMU^STRTAB^BASE register 320 can be used to provide a pointer to the location in memory where the stream table is stored. Of course, in other examples the stream table could be stored in a memory of the SMMU or even in other storage circuitry such as registers. Nevertheless, in this example, the stream table 310 contains a number of entries. The entries provided here are not exhaustive. A first parameter is the virtual machine identifier 330. This identifies a particular virtual machine or guest operating system and therefore associated a stream table entry with that virtual machine or guest operating system. A second parameter is a translation table pointer 340. In previous examples, with the intervention of the hypervisor, some addresses contained within commands provided by a guest (virtual machine or operating system) would be translated by the hypervisor. As explained above, a guest operating system’s (or virtual machine)’s view of memory does not necessarily correspond with that of the actual physical memory. Thus, an address provided by a guest should be translated to correspond with the physical environment. With the invention of the hypervisor this was possible during the transference process - i.e. while transferring commands from the virtual ring buffers provided to guests to the actual physical ring buffer. However, when the guest has direct access to a command queue this does not necessarily happen. In addition to this, the location from where commands are fetched is translated. For instance, a particular execution environment may refer to the ring buffer by a virtual address and this virtual address should be translated in order to obtain the physical address at which the ring buffer is located. Note that it may not be necessary for all addresses within commands to be translated. For instance, if a guest were to issue a command to invalidate a particular (virtual) memory address then the SMMU can simply stop memory access requests for that memory address. In this situation there is no need for the underlying physical address to be known. Consequently, translation circuitry can be provided as part of the SMMU to perform this translation task. In practice, this translation task can be performed by dedicated circuitry. However, since the SMMU may already provide translation services as part of its memory management functionality, the same circuitry that provides the memory management functionality can be used to translate the addresses provided in the command queue. In other words, the command queue itself becomes a requester to its own memory management functionality. This can be achieved by use of the qSID, which identifies a particular command queue and can be used to access the translation services that would normally be provided to a device 40, 50. Together with the first parameter (above), this therefore provides a correspondence between a qSID and a virtual machine (or guest operating system). The translation table pointer 340 indicates which translation tables should be used in order to translate an address given in a command in the command queue. The translation table can either be looked up dynamically or copied (provided suitable storage exists). A TLB 62 of the SMMU 60 can also be used to cache such translations. Of course, if all devices share a same view of the memory - or more specifically if a particular execution environment does not see a virtual view of memory then such translation may not be necessary. A third parameter is a stall behaviour specifier 350 also known as a fault behaviour specifier. In some situations, a memory fault may occur at the SMMU. For instance, the SMMU may attempt to access (on behalf of one device 40) memory that belongs to another device 50. Alternatively, the SMMU may make a memory access that specifies a stream identifier belonging to a guest operating system or virtual machine that does not own the memory location. In these situations, a memory fault will be raised. Where a memory fault is raised by a processor 20 this can result in an exception that can be responded to. However, that may not be possible in the case of an SMMU. Therefore some specified action should take place. The appropriate action to take place can be encoded in the stall behaviour specifier 350. For instance, this specifier may indicate that the exception should be sent to the CPU 40 for handling. The specifier may indicate that the SMMU 60 should wait for an alternative memory address to be provided, or to wait for a more specific action to be raised by the CPU 40. In some cases, the specifier might indicate that the memory fault should simply be disregarded or ignored. In some cases, the action might be to stop any further operation until instructed by the CPU 40 (e.g. by a hypervisor or other highest execution level software). The fact that a memory fault has occurred can be handled by the SMMUECMDQCONS. FAULT flag 112 that forms part of the SMMUECMDQCONS register 106. Meanwhile, the fact that the memory fault has been acknowledged / handled can be indicated by the SMMUECMDQPROD. FAULT ACK flag 110 that forms part of the S\1\1U EC'MDQ PROD register 104. Further registers may be provided, e.g. to provide the reasons for the fault and / or the type of the fault. Up until this point, no assumptions have been made regarding the type of commands that can be issued by different execution environments. There are a number of ways in which this can be controlled. However, in some examples, a series of flags 114, 116, 118, 120 can be set in, for instance, a virtual SMMU IDR2 register 122 in an emulated SMMU view, each of the flags corresponding to a different command or class of command that can be executed by a non-hypervisor. For instance, a non-hypervisor may be unable to specify that all cached translations in the TLB 62 of the SMMU 60 should be invalidated. However, a non-hypervisor might be able to specify that translations associated with the instructing execution environment should be invalidated. This permission could be set by one of the flags 114. Figure 5 schematically illustrates an example of an SMMU 60 in accordance with some examples. The queue control storage circuitry 204 may take the form of one or more control pages that include the BASE / CONS / PROD registers 102, 104, 106 registers previously discussed. A set of each of these registers 102, 104, 106 may be provided for each command queue that is implemented. Read circuitry 402 can be used to read the command queues from memory 30 and thereby affect a behaviour of memory management functionality provided by memory management circuitry 406. For instance, this might include invalidating some translations from a TLB 62 of the SMMU 60. The memory management circuitry otherwise receives memory access requests from devices 40, 50 (which provide a SID that can be associated with a particular execution environment) and provides the memory management functionality. Translation circuitry 404 is provided to perform memory translations. This may include part of the functionality provided by the memory management circuitry 406 but can also include the translation of addresses provided in the command queues (e.g. the translation of addresses used by a guest operating system into a physical address of the memory 30) and the translation of addresses used to access the command queues (e.g. where the command queues are physically located in memory). The memory management circuitry 406 and the translation circuitry 404 are provided here as separate elements but could be the same circuitry. However, they could be the same circuitry. Finally, parameter storage circuitry is used to access parameters that are used to control the memory management functionality. For instance, this might take the form of a register 122 that points to a location in memory where a stream table is found. The stream table may provide parameters such as the identification of translation tables, and particular behaviour to be taken in the event of a stall or memory fault as previously described. Figure 6 is of a flowchart 500 that shows a method of processing in accordance with some examples. At a step 510, a location of a command queue is specified, e.g. using BASE / CONS / PROD registers 102, 104, 106. At step 520, memory management functionality can be provided - such as memory protection and translation services to devices 40, 50. At step 530, the memory management functionality is altered based on commands provided in the command queue. At step 540, addresses provided in those commands are translated based on a view of memory that corresponds with the execution environment providing the commands. Figure 7 illustrates a simulator implementation that may be used. Whilst the earlier described examples implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties 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 730, optionally running a host operating system 720, supporting the simulator program 710. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment 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, Pages 53 - 63. To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 730), some simulated embodiments may make use of the host hardware, where suitable. The simulator program 710 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 700 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 710. Thus, the program instructions of the target code 700 may be executed from within the instruction execution environment using the simulator program 710, so that a host computer 730 which does not actually have the hardware features of the apparatus 60 discussed above can emulate these features. The simulator code 710 may include memory management program logic 712 for providing the memory management functionality corresponding to the memory management circuitry 406, read program logic 714 for reading an associated command queue and altering a behaviour of the memory management functionality in accordance with the read circuitry 402 and translation program logic 716 for translating addresses provided in the command queue in a manner similar to that described for the translation circuitry 404. The IO devices 40, 50 may generally be identified by one or more physical identifiers or physical stream identifiers (pSIDs). It is, however, generally desirable for these pSIDs to be hidden from levels of execution other than the highest level(s). For instance, the hypervisor or other hypervisor software running at a highest level of execution may be aware of these identifiers so that the appropriate devices can be instructed or communicated with. However, it is generally undesirable for lower execution levels to have access to these identifiers so that a level of control exists between the guests and the supervisor. For instance, this makes it possible for the supervisor or hypervisor to control access to the IO devices 40, 50 or even to hide them entirely from certain guest operating systems or virtual machines. To this end, the guest operating systems / virtual machines used virtual stream identifiers (vSIDs) to identify the IO devices 40, 50. A group of virtual identifiers form a virtual identifier space, which is identified by a qSID. In previously proposed systems where the hypervisor directly controlled access to the IO devices 40, 50 (i.e. by providing a virtual command queue), the hypervisor was in a position to rewrite commands and replace vSIDs provided by the guest operating systems with the pSIDs, which are not available to the guest operating systems / virtual machines. Without supervisor or hypervisor involvement, this translation is performed by the SMMU 60 and by enabling the translation to take place without supervisor or hypervisor involvement, the latency of command issuing can be reduced. Figure 8 shows an example of configuration tables 855 in memory, which are used to provide translation from a (qSID, vSID) pair provided by an execution environment to a pSID that identifies an IO device 40, 50. As explained above, translation is performed in two stages, with each stage being made of two levels. The SMMU^CT register 810 points to a location of the configuration tables 855, specifically the location of a first level of a first stage table 815. By providing two levels of translation for each stage, it is possible to dynamically change the size of the translation tables (as well as a size of the vSID). A command queue (CMDQ) info table (CIT) 800 acts as a first stage of translation. That is, it takes a qSID and provides a virtual translation space. The qSID is used to index into this table 815. For instance, bits from LOG2SIZE -1 to SPLIT of the qSID are used to index into the table 815 (where LOG2SIZE is the number of bits used for the qSID, as defined in the SMVIU CT^ register 860). Each entry 820 of the first stage first level table 815 provides a pointer L2 PTR to a second level of the CIT 800 and a SPAN value, which indicates a number of entries in the second level of the CIT 800. For instance, if the SPAN value is ‘3’ then this indicates that there will be 23 entries in the second stage for the CIT 800. Bits 0 to SPAN-1 of the qSID are then used to select a particular entry of the second level of the CIT. Each entry 830 of the CIT 825 contains a validity flag (V) that indicates whether the entry is valid and an STT BASE value, which indicates the location of a second stage table 835, which defines a virtual translations space that translates vSIDs to pSIDs. Each entry 830 of the CIT 825 also provides a LOG2SIZE value, which indicates a number of bits used to represent the vSID and a SPLIT value that indicates a number of entries in the second stage table 835. The vSID is used to address into the second stage table 835 indicated by the STTBASE value. In particular, the bits LOG2SIZE -1 to SPLIT (both defined in the CIT entry 825) of the vSID are used to index into the second stage table 835 to locate a particular entry. Each entry 840 of the second stage table 835 provides a pointer L2 PTR to the second level of the STT table 805. Each entry 840 also contains a SPAN value that indicates a number of entries in the second level. For instance, if the SPAN value is ‘5’ then this indicates that there will be 25 entries in the second stage for the vSID. Bits 0 to SPAN-1 of the vSID are then used to select a particular entry of the second level of the STT. Each entry 850 of the STT 845 contains a validity flag (V) that indicates whether the entry is valid, and a SID (pSID) to which the vSID translates for the IO device 40, 50. As explained above, by providing two levels for each of the tables 800, 805 it is possible to expand or contract the size of the tables and therefore dynamically alter the size of the tables. For instance, if the first stage table 825 is to be expanded, a new table can be created in memory. A new entry 820 in the first level table 815 can then be created to represent the new table 825. The new entry contains the pointer to the new table 825 and an indication of the number of entries in that table. If a new table is created, the old table can either be maintained or entries can be copied from the old table to the new table (which would cause the qSID values or vSID values to be updated, depending on which of the tables 825, 845 was being replaced). Figure 9 illustrates a first command (CMDCFGICIT) for causing invalidation in the configuration tables. In this case, the command is used to invalidate a CIT entry, which invalidates a virtual translation space. For example, if the command specified that qSID is FF32 and if the value of SPLIT was 28, LOG2SIZE was 32, and SPAN was 4, then this means bits 31 to 28 would be used to locate the first entry of the level one table 815. That is, the value ‘F’ would be used. Then, having located the entry, bits 3 to 0 would be used to locate a specific entry in the level two table 825. In this case, the value ‘2’ would be used. Having located this entry, the entry is then invalidated - as shown in Figure 9, the value of ‘V’ for that entry is set to 0. Typically this command would be used when a virtual machine or guest operating system is disabled / killed / stopped since it essentially removes the address to the virtual to physical SID mapping. In practice, such a command would be carried out after the CAID^Q command (Figure 11). Figure 10 illustrates a second command (CMD CFGI STT VSID) for causing invalidation in the configuration tables. In this case, the command is used to invalidate an STT entry, which invalidates a specific virtual to physical translation. For example, if the command specified that qSID is FF32 and the value of vSID is OxABC 1 and if the value of SPLIT was 28, LOG2SIZE was 32, and SPAN was 4, then this means bits 31 to 28 of the qSID would be used to locate the first entry of the level one table 815. That is, the value ‘F’ would be used. Then, having located the entry, bits 3 to 0 of the qSID would be used to locate a specific entry in the level two table 825. In this case, the value ‘2’ would be used. The STTBASE value would then be obtained to access the level one table of the STT 835. Here, bits 31 to 38 of the vSID would be used to locate the entry, i.e. the value ‘A’ would be used to locate an entry into the level two table 845. There, a value ‘ 1 ’ would be used to select a particular entry. In the example of Figure 10, the entry provided a mapping to a device where the entry indicates that the physical SID 544 was being used. This can then be used to identify a specific IO device 40, 50 based on the physical device that has been assigned that pSID of 544. That particular translation is therefore invalidated. Figure 11 illustrates a third command (CMDCFGISTT), which can be used to invalidate a complete STT for a specific qSID. This command may be used, for instance, when the entire view of the I / O devices for a virtual machine / guest operating system is to be invalidated or indeed, when a virtual machine / guest operating system is retiring (in this situation, prior to the CMDCFGICIT command being performed). The command operates similarly to the CMD CFGI STT VSID command shown in Figure 10, except that having located a particular entry 840 in the stage two table 835, all entries 845 of the STT are invalidated. Figure 12 schematically illustrates an example of an SMMU 60 in accordance with some examples. Read circuitry 402 can be used to read command queues from memory 30 and thereby affect a behaviour of memory management functionality provided by memory management circuitry 406. Although not illustrated, queue control storage circuitry 204 could be provided (e.g. of the type illustrated in Figure 5 and Figure 2) to store data relating to the reading of the command queues from memory 30. The commands that are provided may make reference to a particular IO device 40, 50. In these situations, the IO device 40, 50 will be identified by an identifier that is specific to the execution environment (either a hypervisor or a guest operating system / virtual machine). Where the execution environment is a hypervisor, a physical identifier can be provided and no translation needs to be performed (as can be indicated in the command for instance). Where the execution environment is a guest operating system or something other than the hypervisor that can see the physical stream identifiers associated with IO devices 40, 50, a virtual identifier is provided. This may be provided together with the identifier of a virtual identifier space (although this could also be inferred if the sender of the command is known). In any event, translation circuitry 1204 is provided in order to translate the virtual identifier or virtual stream identifier to a physical stream identifier so that the IO device 40, 50 can be identified. For instance, the command in question might prohibit access to a particular IO device 50 to an area of memory. In this case, the command may need to identify the IO device 50 and this can be done using a virtual identifier by which the execution environment issuing the command knows the IO device 50. This can then be translated by the translation circuitry 1204 so that the command can then be properly executed by the read circuitry 402. Figure 13 is of a flowchart 1300 that shows a method of processing in accordance with some examples. At step 1310, memory management functionality can be provided - such as memory protection and translation services to devices 40, 50. At step 540, virtual identifiers provided in those commands are translated to, for instance, physical identifiers. At a step 1340, the memory management functionality is altered based on commands provided in the command queue. Figure 14 illustrates a simulator implementation that may be used. Whilst the earlier described examples implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties 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 1430, optionally running a host operating system 1420, supporting the simulator program 1410. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment 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, Pages 53 - 63. To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 1430), some simulated embodiments may make use of the host hardware, where suitable. The simulator program 1410 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 1400 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 1410. Thus, the program instructions of the target code 1400 may be executed from within the instruction execution environment using the simulator program 1410, so that a host computer 1430 which does not actually have the hardware features of the apparatus 60 discussed above can emulate these features. The simulator code 1410 may include memory management program logic 1412 for providing the memory management functionality corresponding to the memory management circuitry 406, read program logic 1414 for reading an associated command queue and altering a behaviour of the memory management functionality in accordance with the read circuitry 402 and translation program logic 1416 fortranslating addresses provided in the command queue in a manner similar to that described for the translation circuitry 1204. The present invention could be configured as follows: 1 A. An apparatus comprising: memory management circuitry configured to provide memory management functionality to one or more input / output devices in respect of a memory; read circuitry configured to alter a behaviour of the memory management functionality provided to the one or more input / output devices in response to commands in one of a plurality of associated queues; and translation circuitry configured to translate one or more identifiers in the commands from virtual device identifiers to physical device identifiers that identify the input / output devices. 2A. The apparatus according to 1 A, comprising: a plurality of queue control storage circuits configured to indicate locations of the associated queues, wherein each of the plurality of queue control storage circuits is associable with one of a plurality of execution environments. 3 A. The apparatus according to 2A, wherein the execution environments include one or more virtual machines and one or more hypervisors. the memory management functionality includes address translation for virtual addresses provided by the input / output devices to physical addresses used by the memory. 5 A. The apparatus according to any of 1A-4A, wherein the memory management functionality includes address protection to control access to one or more restricted locations in the memory based on the input / output devices. 6A. The apparatus according to any of 1A-5A, wherein the translation circuitry is configured to translate the one or more identifiers in the commands using one or more configuration tables. 7A. The apparatus according to 6A, wherein the one or more configuration tables define a virtual identifier translation space for each of one or more execution environments. 8A. The apparatus according to 7A, wherein the virtual identifier translation space for a given execution environment is configured to provide a translation for at least some of the input / output devices from a virtual identifier used by the execution environment to a physical identifier. 9A. The apparatus according to 7A, wherein the one or more identifiers comprise an execution environment identifier and a virtual identifier; the execution environment identifier is configured to identify the virtual identifier translation space for a given execution environment; and the virtual identifier is configured to identify a physical identifier for one of the input / output devices using the virtual identifier translation space. a size of the virtual identifier translation space is dynamically configurable. 11 A. The apparatus according to any of 9A-10A, wherein the read circuitry is configured to respond to one of the commands being a virtual space invalidation command by invalidating the virtual identifier translation space belonging to the given execution environment specified in the virtual space invalidation command. 12A. The apparatus according to any of 9A-11 A, wherein the read circuitry is configured to respond to one of commands being a translation invalidation command by invalidating a translation from the physical identifier to the one of the input / output devices in the virtual identifier translation space identified by the given execution environment specified in the translation invalidation command. 13 A. The apparatus according to any of 9A-11 A, wherein the read circuitry is configured to respond to one of commands being an execution environment translation invalidation command by invalidating each virtual identifier translation space belonging to the given execution environment specified in the execution environment translation invalidation command. 14A. The apparatus according to any of 1A-13A, wherein the apparatus is an I0MMU. 15 A. A method comprising: providing memory management functionality to one or more input / output devices in respect of a memory; altering a behaviour of the memory management functionality provided to the one or more input / output devices in response to commands in one of a plurality of associated queues; and translating one or more identifiers in the commands from virtual device identifiers to physical device identifiers that identify the input / output devices. 16A. A computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program comprising: memory management program logic configured to provide memory management functionality to one or more input / output devices in respect of a memory; read program logic configured to alter a behaviour of the memory management functionality in response to commands in an associated queue; and translation program logic configured to translate one or more identifiers in the commands from virtual device identifiers to physical device identifiers that identify the input / output devices. The present invention could also be configured as follows: IB. An apparatus comprising: a plurality of queue control storage circuits, each configured to indicate a location of an associated queue; memory management circuitry configured to provide memory management functionality to one or more input / output devices in respect of a memory; read circuitry configured to alter a behaviour of the memory management functionality in response to commands in the associated queue; and translation circuitry configured to translate one or more addresses in the commands. 2B. The apparatus according to IB, wherein the memory management functionality is provided in respect of a plurality of execution environments. 3B. The apparatus according to 2B, wherein each of the plurality of queue control storage circuits is associable with one of the plurality of execution environments. 4B. The apparatus according to any of 2B-3B, wherein the execution environments include one or more virtual machines and one or more hypervisors. 5B. The apparatus according to any of 1B-4B, wherein the memory management functionality includes address translation for virtual addresses provided by the input / output devices to physical addresses used by the memory. 6B. The apparatus according to any of 1B-5B, wherein each of the plurality of queue control storage circuits is dynamically associable with one of the plurality of execution environments at runtime. 7B. The apparatus according to any of 1B-6B, wherein the translation circuitry is the memory management circuitry. 8B. The apparatus according to any of 1B-7B, wherein the memory management functionality includes address protection to control access to one or more restricted locations in the memory based on the input / output devices. 9B. The apparatus according to any of 1B-8B, comprising: a plurality of parameter storage circuits, each usable to obtain one or more memory management parameters for controlling the memory management functionality. a plurality of parameter storage circuits, each configured to store a location of one or more memory management parameters for controlling the memory management functionality. 1 IB. The apparatus according to any of 9B-10B, wherein the memory management parameters comprise translation data for use with the translation circuitry. 12B. The apparatus according to any of 9B-1 IB, wherein the memory management parameters comprise a fault behaviour specifier; and in response to a memory fault, an action is taken in accordance with the fault behaviour. 13B. The apparatus according to any of 9B-12B, wherein the memory management parameters comprise an indication of an execution environment; and the memory management functionality is performed in respect of the execution environment. 14B. The apparatus according to any of 1B-13B, wherein the apparatus is an I0MMU. 15B. The apparatus according to any of 1B-14B, wherein the translation circuitry is configured to translate one or more addresses in the plurality of queue control storage circuits. 16B. The apparatus according to any of 1B-15B, wherein the memory management circuitry is configured to receive a device request for the memory management functionality from the one or more input / output devices, wherein the device request contains an input / output device identifier; and the translation circuitry is configured to translate one or more addresses in the command by issuing a queue request for the memory management functionality; and the queue request contains a queue identifier of the associated queue of one of the plurality of queue control storage circuits. 17B. The apparatus according to 16B, wherein the queue identifier is configured to correspond in format with the input / output device identifier. 18B. A method comprising: indicating a location of an associated queue; providing memory management functionality to one or more input / output devices in respect of a memory; altering a behaviour of the memory management functionality in response to commands in the associated queue; and translating one or more addresses in the commands. 19B. A computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program comprising: memory management program logic configured to provide memory management functionality to one or more input / output devices in respect of a memory; read program logic configured to alter a behaviour of the memory management functionality in response to commands in an associated queue; and translation program logic configured to translate one or more addresses in the commands. In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation. 5 Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes, additions and modifications can be effected therein by one skilled in the art without 10 departing from the scope and spirit of the invention as defined by the appended claims. For example, various combinations of the features of the dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.

Claims

1. An apparatus comprising:memory management circuitry configured to provide memory management functionality to one or more input / output devices in respect of a memory;read circuitry configured to alter a behaviour of the memory management functionality provided to the one or more input / output devices in response to commands in one of a plurality of associated queues; andtranslation circuitry configured to translate one or more identifiers in the commands from virtual device identifiers to physical device identifiers that identify the input / output devices.

2. The apparatus according to claim 1, comprising:a plurality of queue control storage circuits configured to indicate locations of the associated queues, whereineach of the plurality of queue control storage circuits is associable with one of a plurality of execution environments.

3. The apparatus according to claim 2, whereinthe execution environments include one or more virtual machines and one or more hypervisors.

4. The apparatus according to any preceding claim, whereinthe memory management functionality includes address translation for virtual addresses provided by the input / output devices to physical addresses used by the memory.

5. The apparatus according to any preceding claim, whereinthe memory management functionality includes address protection to control access to one or more restricted locations in the memory based on the input / output devices.

6. The apparatus according to any preceding claim, whereinthe translation circuitry is configured to translate the one or more identifiers in the commands using one or more configuration tables.

7. The apparatus according to claim 6, whereinthe one or more configuration tables define a virtual identifier translation space for each of one or more execution environments.

8. The apparatus according to claim 7, whereinthe virtual identifier translation space for a given execution environment is configured to provide a translation for at least some of the input / output devices from a virtual identifier used by the execution environment to a physical identifier.

9. The apparatus according to claim 7, whereinthe one or more identifiers comprise an execution environment identifier and a virtual identifier;the execution environment identifier is configured to identify the virtual identifier translation space for a given execution environment; andthe virtual identifier is configured to identify a physical identifier for one of the input / output devices using the virtual identifier translation space.

10. The apparatus according to claim 9, whereina size of the virtual identifier translation space is dynamically configurable.

11. The apparatus according to any one of claims 9-10, whereinthe read circuitry is configured to respond to one of the commands being a virtual space invalidation command by invalidating the virtual identifier translation space belonging to the given execution environment specified in the virtual space invalidation command.

12. The apparatus according to any one of claims 9-11, whereinthe read circuitry is configured to respond to one of commands being a translation invalidation command by invalidating a translation from the physical identifier to the one of the input / output devices in the virtual identifier translation space identified by the given execution environment specified in the translation invalidation command.

13. The apparatus according to any one of claims 9-11, whereinthe read circuitry is configured to respond to one of commands being an execution environment translation invalidation command by invalidating each virtual identifier translation space belonging to the given execution environment specified in the execution environment translation invalidation command.

14. The apparatus according to any preceding claim, whereinthe apparatus is an I0MMU.

15. A method comprising:providing memory management functionality to one or more input / output devices in respect of a memory;altering a behaviour of the memory management functionality provided to the one or more input / output devices in response to commands in one of a plurality of associated queues; andtranslating one or more identifiers in the commands from virtual device identifiers to physical device identifiers that identify the input / output devices.

16. A computer program for controlling a host data processing apparatus toprovide an instruction execution environment, the computer program comprising:memory management program logic configured to provide memory management functionality to one or more input / output devices in respect of a memory;read program logic configured to alter a behaviour of the memory management functionality in response to commands in an associated queue; and translation program logic configured to translate one or more identifiers in the commands from virtual device identifiers to physical device identifiers 5 that identify the input / output devices.

Images