TWI752951B - An apparatus and method for performing operations on capability metadata - Google Patents

Abstract

An apparatus is provided comprising storage elements to store data blocks, where each data block has capability metadata associated therewith identifying whether the data block specifies a capability, at least one capability type being a bounded pointer. Processing circuitry is then arranged to be responsive to a bulk capability metadata operation identifying a plurality of the storage elements, to perform an operation on the capability metadata associated with each data block stored in the plurality of storage elements. Via a single specified operation, this hence enables query and/or modification operations to be performed on multiple items of capability metadata, hence providing more efficient access to such capability metadata.

Description

Apparatus and method for performing operations on capability metadata

The present technology relates to apparatus and methods for performing operations on capability metadata.

There is a growing interest in capability-based architectures, where some capabilities are defined for a given process and attempts to perform operations outside of the defined capabilities may trigger errors. These capabilities can take various forms, but one type of capability is a bounded pointer (also known as a "fat pointer"). For bounded pointers, the pointer value may identify or be used to determine, for example, the data value to be accessed or the address of the instruction to be executed. However, a pointer value may also have associated range information indicating the allowable range of addresses when using the pointer value. This can be used, for example, to ensure that addresses determined by the pointer remain within certain boundaries to maintain behavioral safety or functional correctness. Additionally, certain permission/restriction information may be specified in association with the pointer value of the bounded pointer. Scope information and any permission/restriction information about bounded pointers may be referred to as capability information, and in a capability-based architecture, such bounded pointers (including their associated capability information) may be referred to as capabilities.

In a capability-based architecture, it is known to store capability metadata associated with each data block stored in a storage element of a device. Capability metadata may be used to identify whether the relevant data block specifies a capability, or alternatively contains data that does not represent a capability (also referred to herein as generic data). Capability metadata may also specify some additional information, if desired.

When accessing an individual data block, the relevant capability metadata can be referenced to determine whether the data block represents capability or generic data. However, it is desirable to provide improved mechanisms for accessing and manipulating capability metadata in systems employing capability-based architectures.

In a first example configuration, an apparatus is provided comprising: a storage element for storing data blocks, each data block having capability metadata associated therewith to identify whether the data block specifies a capability, and at least one capability type is a bounded pointer and processing circuitry, responsive to a batch capability metadata operation identifying a plurality of the storage elements, performing an operation on capability metadata associated with each block of data stored in the plurality of storage elements.

In another example configuration, a method of performing an operation on capability metadata is provided, comprising: storing data blocks in a storage element, each data block having capability metadata associated therewith to identify whether the data block specifies a capability, at least one The capability type is a bounded pointer; and in response to a batch capability metadata operation identifying a plurality of the storage elements, causing the processing circuitry to perform an operation on the capability metadata associated with each block of data stored in the plurality of storage elements.

In yet another example configuration, an apparatus is provided comprising: a storage element component for storing data blocks, each data block having capability metadata associated therewith to identify whether the data block specifies a capability, at least one capability type being a bounded pointer ; and a processing component for performing an operation on the capability metadata associated with each data block stored in the plurality of storage component components in response to a batch capability metadata operation identifying the plurality of the storage component components.

In yet a further example configuration, there is provided a computer program product storing a computer program in a non-transitory form for controlling a computer to provide a sequence of program instructions for a device corresponding to a device according to the first example configuration discussed above Virtual machine execution environment.

Before discussing the embodiments with reference to the figures, the following description of the embodiments is provided.

As mentioned earlier, there is a growing interest in capability-based architectures, where certain capabilities are defined for a given process and attempts to do something outside of the defined capabilities may trigger errors. Various types of capabilities can be defined, but one type of capability is a bounded pointer (which in one embodiment combines the pointer value with associated scope and permission information). Devices employing this capability-based architecture will typically have storage elements (also referred to herein as bounded pointer storage elements) for storing capabilities. The storage elements may be registers (also referred to herein as bounded pointer registers or capability registers) and/or may be at memory locations in general-purpose memory, such as locations on stacked memory. Certain instructions may be used to reference these storage elements to access a desired capability and perform operations dependent on that capability. Considering, for example, bounded pointers, execution of such an instruction may result in the bounded pointer being fetched, and the pointer value therein, then used to derive an address in memory required during execution of the instruction. The pointer value can be used directly to identify the memory address, or it can be used to derive the memory address, for example, by incrementing the offset of the pointer value. The operation will be allowed if the memory address is in the range specified by the range information and satisfies any permissions specified in the permission information.

Capability metadata may be provided in association with each data block stored in the storage element to identify whether the data block represents a capability, or alternatively generic data. According to embodiments described herein, the apparatus is arranged to perform bulk capability metadata operations to allow bulk query and/or modification of capability metadata associated with a plurality of storage elements.

More specifically, in one embodiment, an apparatus is provided that includes a storage element to store data blocks, each data block has capability metadata associated therewith to identify whether the data block specifies a capability, at least one capability type is bounded pointer. The processing circuitry then performs operations on the capability metadata associated with each block of data stored in the plurality of storage elements in response to identifying the batch capability metadata operations for the plurality of storage elements.

According to the described embodiments, rather than accessing capability metadata for individual items in response to operations targeting capability metadata and/or associated data blocks for a particular item, batch capability metadata operations that identify a plurality of storage elements may be specified . Processing circuitry may then perform operations on the capability metadata associated with each block of data stored in the plurality of storage elements in response to this batch capability metadata operation. Bulk capability metadata operations directly target multiple capability metadata and do not require access to related data blocks during the operation. Thus, this provides a particularly efficient mechanism to perform operations on multiple capability metadata in response to a single batch request identifying multiple storage elements whose associated capability metadata is to be accessed.

Such operations can be used in a variety of situations. Such operations may be useful, for example, when memory paging between capability-aware storage elements and capability-agnostic backup storage or when migrating virtual machines across networks that lack native capability support. The provision of batch capability metadata operations can significantly increase the efficiency and performance of these operations.

The batch capability metadata operation can take various forms, but in one embodiment is a batch query operation and the processing circuitry responds to the batch query operation to obtain the capabilities associated with each data block stored in a plurality of the storage elements metadata, and used to generate output data containing the acquired capability metadata. Thus, when such bulk query operations are performed, capability metadata about the various items of the identified plurality of storage elements is retrieved and aggregated together to form output data. The output data can then be used for various purposes, such as the output data can be written to a general purpose register, the output data can be subsequently written out from the general register to a capability-agnostic entity such as backup storage, or actually in In some embodiments, it may be possible to write the output data directly into such backup storage.

However, batch capability metadata operations need not be batch query operations. In an alternate embodiment, the batch capability metadata operation is a batch modification operation, and the processing circuitry is responsive to the batch modification operation to modify and store in the plurality of the stores depending on modification data specified for the batch modification operation Capability metadata associated with each data block in the component. Thus, in these embodiments, modification data for subsequent selectively updating capability metadata associated with each of the identified plurality of storage elements may be specified, thereby providing a means of updating multiple capability metadata in response to the operation of a single identification. Very effective mechanism.

Bulk edit operations can take various forms. In one embodiment, this may result in capability metadata associated with each data block stored in the plurality of storage elements being set to identify each data block specifying capabilities, or alternatively may result in capability metadata associated with each data block Cleared to identify individual data blocks specifying data other than capabilities (also referred to herein as generic data).

In an alternate embodiment, for each capability metadata to be accessed by the bulk modification process, the modification data may identify the modification performed on the capability metadata. Thus, in such embodiments, the same modifications do not necessarily have to be performed on each capability metadata, but the modifications may instead be specified at a finer granularity.

In one embodiment, the modification data provides a modification value for each capability metadata to be accessed by the bulk modification operation, the modification value identifying one of at least two of the following modifications: (i) setting the capability metadata to identify the associated data block specification capabilities; (ii) clear capability metadata to identify data other than capabilities specified by the relevant data block; and (iii) leave capability metadata unchanged. Such approaches provide a great deal of flexibility as to how the capability metadata of individual items is updated during the bulk modification process.

Although in some embodiments, batch capability metadata operations may be performed unconditionally, in an alternative embodiment, processing circuitry may be arranged to perform batch capability metadata operations subject to conditions. This can enhance process security by making the execution of batch capability metadata operations conditional. For example, given the bulk modification operation in particular, it should be understood that the ability to modify capability metadata for multiple storage elements is a powerful tool, and it may be desirable to limit the ability to perform such bulk modification for certain specific situations.

For example, in one embodiment, a condition may be determined to be satisfied if at least one of the following conditions is true: (i) the processing circuitry is operating in a predetermined privileged state; (ii) when the processing circuitry is in a predetermined privileged state The configuration storage element that can be set during operation has a value indicating that the batch capability metadata operation is allowed; (iii) the request specifying the batch capability metadata operation identifies the batch operation capability, and the batch operation capability indicates that the batch capability metadata operation is allowed. In this way, it is possible to effectively limit the situations in which the batch capability metadata operation can be performed if necessary.

A storage element whose capability metadata is manipulated by bulk capability metadata operations can take various forms. For example, in one embodiment a storage element may be a memory location accessible to processing circuitry.

In one embodiment, the plurality of memory locations may be specified with reference to a bounded pointer, and when it is determined that the plurality of memory locations reside within the allowable address range identified by the bounded pointer, the processing circuitry is arranged to execute the batch Capability metadata manipulation. Thus, regardless of whether the execution of batch capability metadata operations is made conditional, such as using any of the previously discussed techniques, if bounded pointers are also used to specify memory locations, the capability metadata can be guaranteed by ensuring its associated capability metadata An additional level of checking is performed by resident memory locations manipulated by bulk capability metadata operations within the allowable address range identified by the bounded pointer.

Although some bulk capability metadata operations may be performed relative to memory locations, in an alternative embodiment or in addition, certain bulk capability metadata operations may be performed on capability elements associated with capability registers accessible to processing circuitry data application. Such capability registers may be arranged to store capabilities, such as the previously mentioned bounded pointers, and each capability register will have capability metadata associated with it to identify whether the current contents of the capability register actually represent capabilities, or alternatively will be processed as generic data.

There are several ways in which this batch capability metadata operation can be specified. However, in one embodiment, a single instruction is used to specify each batch capability metadata operation. For example, in one embodiment, the apparatus may further include decoding circuitry to generate, in response to a sequence of instructions, control signals for issuance to processing circuitry to cause the processing circuitry to perform operations required by the sequence of instructions. Decoding circuitry may be arranged to generate control signals in response to receiving a bulk capability metadata instruction for issuance to processing circuitry to cause the processing circuitry to perform the bulk capability metadata operations required by the bulk capability metadata instruction. Thus, the processing circuitry may be, for example, a processor core that is responsive to control signals generated by the decoding circuitry to perform operations required by the decoded instructions. When the decoding circuitry decodes the batch capability metadata instruction, the processing circuitry will perform the requested batch capability metadata operation in response to the resulting control signal generated. It should be understood that such approaches may specify batch queries and/or modifications to be performed on multiple items of capability metadata associated with identified multiple storage elements (which may be memory locations or registers) by enabling single instructions. operation to provide significant performance and code density benefits.

There are several ways in which a plurality of storage elements whose capability metadata is to be accessed/manipulated by a batch capability metadata operation can be specified in an instruction. For example, in one embodiment, the storage element is a memory location and the batch capability metadata instruction specifies a register that provides an address that identifies a contiguous series of memory locations whose associated capability metadata will be subjected to a batch capability metadata operation . The address specified by the scratchpad may take various forms, but in one embodiment may be, for example, the start address.

There are various ways in which the number of memory locations in a continuous series can be identified. For example, in one embodiment, the batch capability metadata command may include a field identifying the number of memory locations in a contiguous series. Thus, in these examples, the instruction may unambiguously identify the number of memory locations subject to batch-capable metadata operations.

Fields identifying the number of memory locations can take various forms. For example, a field may provide a reference to a register containing a value indicating the number of memory locations in a continuous series. Alternatively, an immediate value can be specified in a field that directly indicates the number of memory locations in a continuous series.

In an alternative embodiment, batch capability metadata instructions may not be required to explicitly identify the number of memory locations in a contiguous series. For example, in one embodiment, the number of memory locations may be implied by device properties. The device property that defines the number of memory locations can take various forms, but in one embodiment, the property is the cache line length of the cache that the processing circuitry can access. Such approaches allow structures such as data caches of processors to be exploited. In particular, where such a cache utilizes capability metadata for each data block located in the cache line to augment cache line information, it is possible to facilitate this through the use of such instructions. Management operations like capability metadata, and this can be used, for example, to optimize paging codes used to move capabilities between capability-aware memory systems and backup storage, or vice versa.

In one embodiment, the batch capability metadata instruction identifies the capability register as a plurality of storage elements. In such embodiments, the batch capability metadata instruction may include a register identifier field that identifies the capability registers whose associated capability metadata will be subjected to the batch capability metadata operation, the register identifier field At least one of an immediate value and a register identifier is provided to identify the capability register. When performing these bulk operations on capability metadata associated with a plurality of capability registers, the registers are generally not required to be registers in a contiguous sequence, and thus there is a large amount of information on how to identify individual registers flexibility. For example, a mask value may be used to identify the associated register as an immediate value or a reference to a register containing the mask value. Alternatively, a combination of a base register identifier and a count value can be used to identify a register, wherein the base register identifier or count value is referenced to the general register specification, and the base register identifier and count value are The other is specified by an immediate value, for example.

Bulk capability metadata directives can take various forms. In one embodiment, it takes the form of a bulk query instruction, and the processing circuitry is arranged to perform a bulk query operation in response to control signals generated by decoding circuitry when decoding the bulk query instruction. The batch query command can identify the destination register, and the processing circuitry responds to the batch query operation to obtain capability metadata associated with each data block stored in the plurality of storage elements and to generate capabilities containing the obtained capabilities Metadata output data for storage in the destination register. Thus, in response to a single instruction, capability metadata associated with multiple storage elements can be aggregated and stored in a single destination register.

In some examples, the batch capability metadata instruction may be a batch modification instruction, and the processing circuitry is arranged to perform the batch modification operation in response to control signals generated by the decoding circuitry when decoding the batch modification instruction. The bulk modify instruction may identify a source field for identifying modified data, and the processing circuitry responds to the bulk modify operation to modify and store each of the plurality of storage elements depending on the modified data identified by the source field Capability metadata associated with the data block.

The source field can identify modified data in various ways. For example, the source field can provide immediate values and/or register identifiers to identify modified data. In one embodiment, where the storage element is a memory location, a general purpose register containing modified data is identified. However, where the storage element is a capability register, then in one embodiment either or both an immediate value and a register identifier may be specified to identify the modification data. In yet another embodiment, also when the storage element is a memory location, either or both of the immediate value and the register identifier may be used to identify the modification data.

In one embodiment where the processing circuitry is arranged to perform bulk query operations as bulk capability metadata operations, the processing circuitry may be further arranged to output data containing the obtained capability metadata for storage in capability agnostic in the storage element. It can output data directly for storage in the capability agnostic storage element, or the output data can be initially stored in a general purpose register from which the output data can be forwarded to the capability agnostic storage element.

In one embodiment where the processing circuitry is arranged to perform batch modification operations as batch capability metadata operations, the modification data used may be obtained from capability agnostic storage elements. Although in one embodiment, the modification data may be obtained directly from the capability-agnostic storage element, in an alternative embodiment, the modification data may be first written from the capability-agnostic storage element to a general-purpose register, and then stored in the The modification data is referenced by the processing circuitry from the general purpose register during execution of a bulk modification operation.

Instead of processing circuitry, which is a processor core that executes instructions decoded by associated decoding circuitry, the processing circuitry may in an alternative embodiment be direct memory access (DMA) circuitry. In such embodiments, a batch capability metadata operation may be specified by a processor core and cause the DMA circuit to issue one or more transactions to perform the batch capability metadata operation on a contiguous series of memory locations. Thus, in such embodiments, where the processor pipeline can access memory that is also accessible by the DMA circuitry, the processor pipeline can offload batch capability metadata operations to the DMA circuitry, where the DMA circuitry The system then performs the required operations via a series of transactions between the DMA circuitry and the associated memory locations. Thus, in such embodiments, batch capability metadata operations are effectively expressed as a bus protocol level to allow DMA circuits to access/manipulate a set of capability metadata items about memory regions.

Particular embodiments will now be described with reference to the accompanying drawings.

Figure 1 schematically illustrates an example of a data processing apparatus 2 including a processing pipeline 4 for processing instructions. In this example, processing pipeline 4 includes several pipeline stages including fetch stage 6, decode stage 8, issue stage 10, execute stage 12, and writeback stage 14, although it should be understood that other types of level or combination of levels. For example, a renaming stage for performing scratchpad renaming may be included in some embodiments. Pending instructions move between stages, and while an instruction is pending at one stage, another instruction may be pending at a different stage of pipeline 4 .

Fetch stage 6 fetches instructions from level 1 ( L1 ) instruction cache 20 . Fetch stage 6 can typically fetch instructions sequentially from consecutive instruction addresses. However, the fetch stage may also have a branch predictor 22 for predicting the outcome of the branch instruction, and the fetch stage 6 may fetch the instruction from the (non-sequential) branch target address if a branch is predicted to be taken, or if the prediction does not Taking the branch, fetch stage 6 fetches the instruction from the next sequential address. Branch predictor 22 may include one or more branch history tables for storing information for predicting whether certain branches can be taken. For example, the branch history table may include a counter used to track the actual outcome of previously executed branches or to represent the confidence of predictions made on branches. The branch predictor 22 may also include a branch target address cache (BTAC) 24 for caching the previous target address of a branch instruction so that this can be predicted when the same branch instruction is subsequently encountered Wait for the previous target address.

The fetched instructions are passed to decode stage 8 which decodes the instructions to produce decoded instructions. The decoded instructions may include control information for controlling execution stage 12 to perform appropriate processing operations. For some of the more complex instructions fetched from cache 20, decode stage 8 may map those instructions to a number of decoded instructions, which mapping may be known as micro-ops (μops or uops). Therefore, there may not be a one-to-one correspondence between instructions fetched from L1 instruction cache 20 and instructions seen by subsequent stages of the pipeline. In general, references to "instructions" in this application should be construed to include micro-operations.

The decoded instruction is passed to issue stage 10, which determines whether operands required to execute the instruction are available, and when the operands are available, issues the instruction for execution. Some embodiments may support in-order processing, whereby instructions are issued for execution in an order corresponding to the program order in which the instructions were fetched from L1 instruction cache 20. Other embodiments may support out-of-order execution, such that instructions may be issued to execution stage 12 in an order other than program order. Out-of-order processing can be used to improve performance because, although an earlier instruction is stalled while waiting for an operand, an instruction whose operand is available can be executed first in program order.

Issue stage 10 issues instructions to execution stage 12, where the instructions are executed to perform various data processing operations. For example, the execution stage may include a number of execution units 30, 32, 34, including an arithmetic/logic unit (ALU) 30 that performs arithmetic or logic operations on integer values, and operates on values represented in floating point form. floating-point (FP) unit 32, and for performing a load operation of loading data values from level 1 (L1) data cache 36 into register 40 or loading data values from the register 40 Load/store unit 34 for store operations that store to L1 data cache 36 . It should be understood that these are only a few examples of the types of execution units that may be provided, and that many others may also be provided. For processing operations, execution stage 12 may read data values from a set of registers 40 . The results of executing the instructions may then be written back to the scratchpad 40 by the writeback stage 14 .

L1 instruction cache 20 and L1 data cache 36 may be part of a cache hierarchy that includes multi-level caches. For example, a level 2 (L2) cache 44 may also be provided and other levels of cache may be provided as appropriate. In this example, L2 cache 44 is shared between L1 instruction cache 20 and L1 data cache 36, although other examples may have separate L2 instruction and data caches. When the instruction to be fetched is not in the L1 instruction cache 20, it can be fetched from the L2 cache 44, and similarly if the instruction is not in the L2 cache 44, it can be fetched from the main The memory 50 is retrieved. Similarly, in response to a load instruction, if the data is not in L1 data cache 36, it can be fetched from L2 cache 44 and, if necessary, from memory 50. Any known scheme can be used to manage the cache hierarchy.

The addresses used by pipeline 4 to represent program instructions and data values may be virtual addresses, but at least the main memory 50, and optionally at least some levels of the cache hierarchy, may be physically addressed. Therefore, a translation lookaside buffer 52 (translation lookaside buffer; TLB) may be provided for translating the virtual addresses used by the pipeline 4 into physical addresses for accessing the cache or memory. For example, TLB 52 may include several entries, each of which specifies a virtual page address and a corresponding physical page address of a corresponding page of the virtual address space, and the virtual page address should be mapped to the corresponding physical page address to be used in the corresponding Virtual addresses in the page are converted to physical addresses. For example, virtual and physical page addresses may correspond to the most significant portions of the corresponding virtual and physical addresses, while the remaining least significant portions remain unchanged when mapping virtual addresses to physical addresses. In addition to address translation information, each TLB entry may also include some information specifying access permissions, such as indicating whether certain pages of an address are accessible in certain modes of pipeline 4. In some embodiments, the TLB entry may also define other properties of the corresponding page of the address, such as cache policy information that defines which level of the cache hierarchy is updated in response to a read or write operation (eg, the whether the cache should operate in write-back or write-through mode), or defines whether data accesses to addresses in the corresponding page can be reordered by the memory system compared to the order in which data accesses are issued by pipeline 4 Information.

Although Figure 1 illustrates a single-level TLB 52, it should be understood that a TLB hierarchy may be provided such that a level-1 (L1) TLB 52 may include TLB entries for translating addresses in several recently accessed pages and may provide Level 2 (L2) TLB for storing large page entries. When the desired entry does not exist in the L1 TLB, it can be retrieved from the L2 TLB, or retrieved from other TLBs in the hierarchy. If the desired entry to access the page is not in any TLB, a page table walk may be performed to access the page table in memory 50 . Any known TLB management scheme can be used in the present technology.

In addition, it should be appreciated that some systems may support multi-level address translation, such that, for example, a first TLB (or TLB level) can be used to translate virtual addresses to intermediate addresses, and second-order address translation using one or more other TLBs The intermediate addresses can then be translated into physical addresses used to access the cache or memory. This can be used to support virtualization, where, for example, first-order address translation can be managed by the operating system and second-order address translation can be managed by a hypervisor.

As shown in FIG. 1 , the device 2 may have a set of bounded pointer registers 60 . Although the set of bounded pointer registers is shown physically separate from the set of general data registers 40 in FIG. 1, in one embodiment, the same physical store may be used to provide the general data registers and bounded Both pointer registers.

Each bounded pointer register 60 includes a pointer value 62 that can be used to determine the address of the data value to be accessed, and range information 64 that specifies the allowable address range when the corresponding pointer 62 is used. The bounded pointer register 60 may also include restriction information 66 (also referred to herein as permission information) that may define one or more restrictions/permissions on the use of the pointer. For example, limit 66 may be used to limit the types of instructions that may use pointer 62 or the mode of pipeline 4 that may use the pointer. Thus, scope information 64 and limit information 66 may be considered to define the capabilities within which pointer 62 is allowed to be used. An error may be triggered when attempting to use a pointer 62 outside of the defined capabilities. Range information 64 may be used, for example, to ensure that pointers remain within certain known boundaries and do not stray into other areas of the memory address space that may contain sensitive or secure information. In one embodiment where the same physical storage is used for both the general purpose data register and the bounded pointer register, then in one embodiment the pointer value 62 may be stored, for example, in the same location as used for the corresponding general purpose register in the storage location.

Figure 2 illustrates examples of command types whose allowable ranges are used to prevent unauthorized access to data or commands. As shown at the top of Figure 2, the specific bounded pointer register PR1 includes a given pointer value 62 and range information 64, which in this example is using the lower bound bit that defines the lower bound of the allowable range Address 68 and address 69 which define the upper bound of the upper bound of the allowable range are specified. For example, boundaries 68, 69 are set to define the address range 80000 to 81000. An error can be triggered when certain instructions refer to the bounded pointer register PR1 and the address determined by the pointer 62 is out of this range.

For example, as shown in part A of FIG. 2, in some systems, an attempt to set the value of pointer 62 in pointer register 60 to a value outside the range specified by range information 64 may trigger an error ( It is assumed here that the pointer directly specifies the address). This prevents pointer 62 from taking any value outside the specified range, so that any access using the pointer can be assured to be safely within the allowable range. Alternatively, as shown in Part B of Figure 2, an error may be triggered when the instruction attempts to access the location identified by the address of pointer 62 when the address is outside the specified range. Therefore, it is still permissible to set the pointer 62 to a value outside the specified range, but if the address is outside the permissible range, once a data access attempt at the pointer address (or an address derived from the pointer) is attempted, the Trigger an error. Other systems may trigger errors in response to both the types of instructions illustrated in Parts A and B of FIG. 2 .

The range information 64 can be set in different ways. For example, security code or the operating system or hypervisor may dictate the allowable range for a given pointer. For example, an instruction set architecture may include several instructions for setting or modifying scope information 64 for a given pointer 62, and may restrict execution of such instructions to certain software or certain modes or exception states of processor 4. Any known technique for setting or modifying the scope information 64 may be used.

In addition to the set of bounded pointer storage elements 60 that can be used in execute state 12 when certain instructions referencing the pointer are executed, the program counter capability (PCC) register 80 can also be used when an instruction is Level 1 instruction cache 20 provides similar functionality at fetch stage 6 when fetching. In particular, program counter pointers may be stored in field 82, where PCC 80 also provides range information 84 and any suitable limit information 86, similar to the ranges provided by the pointers in the set of bounded pointer storage elements 60 and restricted information.

Figure 3 schematically illustrates how tag bits are used in association with individual data blocks to identify whether they represent capabilities (ie, bounded pointers and associated restriction information), or normal data. In particular, the memory address space 110 will store a series of data blocks 115, which will typically be of a specified size. For the sake of illustration only, it is assumed in this example that each data block contains 128 bits. Associated with each data block 115, a tag field 120 is provided, which in one example is a single bit field called a tag bit, which is set to identify the associated data block Represents a capability, and is cleared to indicate that the associated data block represents normal data and therefore cannot be processed as a capability. It should be understood that the actual value associated with the set or clear state may vary depending on the embodiment, but by way of illustration only, in one embodiment, if the tag bit has a value of 1, it indicates that the associated data block is capable, And if it has a value of 0, it indicates that the relevant data block contains normal data.

When a capability is loaded into one of the bounded pointer registers 60 (also referred to herein as capability registers), such as capability register 100 shown in FIG. 3, then the tag bits move with the capability information . Thus, when a capability is loaded into the capability register 100, the pointer 102, scope information 104 and restriction information 106 (hereinafter referred to as permission information) will be loaded into the capability register. In addition, associated with, or as a specific bit field in the capability register, tag bit 108 will be set to identify the content representation capabilities. Similarly, when a capability is stored back into memory, the associated tag bit 120 will be set in association with the data block in which the capability is stored. In this way, it is possible to distinguish abilities from normal data and thus ensure that normal data cannot be used as abilities.

Although in Figure 3 reference has been made to a tag field containing tag bits, in a more general embodiment, tag bits are examples of capability metadata that can be associated with various capabilities. Thus, as shown in FIG. 4, a capability 150 stored in a storage element of the system (whether it is one of capability registers 60 or a memory location in memory address space 110) may have capability metadata associated with it 155. Capability metadata will identify whether relevant data blocks 150 actually represent capabilities or should instead be interpreted as generic data, and in one embodiment, this information is encoded as tag bits in capability metadata 155 . In one embodiment, the capability metadata may contain only the tag bits, but in alternative embodiments may contain additional information if desired. For example, data types may be further subdivided, with capability metadata indicating ownership, eg, by specific priority levels, fine-grained permissions (eg, read-only), and the like.

These capabilities can take various forms, but in the embodiment shown in Figure 4, the capabilities are bounded pointers. As shown, a bounded pointer consists of pointer value 160 , scope information 165 and permission attribute 170 . The scope information and permission attributes may be collectively referred to as the attributes of a bounded pointer.

In one embodiment, the execution pipeline 12 shown in FIG. 1 is arranged to execute instructions to perform batch capability metadata operations on the identified plurality of storage elements, resulting in pairing and storage in the identified plurality of storage elements The operation is performed on the capability metadata associated with each data block. Bulk capability metadata operations can take various forms. For example, one form of bulk capability metadata operation may be a bulk query operation, while another example form of a bulk capability metadata operation may be a bulk modify operation.

Figures 5A and 5B illustrate fields that may be provided in two different types of instructions that may be executed by execution stage 12 to perform a Item capability metadata to perform batch query operations. These memory locations may reside in memory 50 as shown in FIG. 1, or in one of the various levels of cache memory 36,44.

As shown in FIG. 5A, an instruction called the CQueryTagsM instruction may be fetched via the level 1 instruction cache 20 of FIG. 1 for decoding by decode stage 8 to generate a sequence of control signals that will be subsequently Control execution stage 12 performs a lookup operation on a plurality of tag bits associated with a plurality of data blocks identified by the instruction (in this embodiment, it is assumed that each capability metadata contains tag bits, as previously described, for example, with reference to FIG. 3 discussion). As shown in Figure 5A, the operation code field 205 identifies the command as a CQueryTagsM command. Field 210 is used to identify an address from which a plurality of memory locations for which tag bits will be queried can be determined. In one embodiment, the address is the start address for the sequence of memory locations, and the start address may be specified in one of the capability registers 60 or one of the general purpose registers 40, where field 210 Include the identifier of the register. In one embodiment, the address will be aligned to the capability memory location, ie, the beginning of one of the data blocks 115 illustrated in the memory address space 110 of FIG. 3 . In an alternative embodiment, the starting address may not need to be specified in an aligned manner, but instead any bits that cause the specified address to be misaligned may be ignored, so the address specified in field 210 will be effectively transformed for the alignment address.

In the example of the command in Figure 5A, the number of memory locations whose tag bits are queried is explicitly defined in the command via the usage field 215. In one embodiment, field 215 may identify a general register whose contents identify the number of tags to be queried. Alternatively, an immediate value can be specified in field 215 to directly identify the number of tags to query.

An additional field 220 is then provided to identify the general register 40 to which the query results will be output. Thus, when execution stage 12 executes a sequence of operations to retrieve tag bits for each of the identified memory locations, the tag bits are then sorted together into output data values that are output for storage in in one of the general purpose registers 40.

If desired, in instruction 200 (and indeed in any of the instructions described herein), one of the source registers may be specified to be the same as the destination register. So for example, if a general purpose register is specified in field 215 to identify the number of tags to be queried, then the same general register can be specified as the register where the query results are written (allowing for example the combination of fields 215, 220 to form a single field). This reduces the constraints on the code space requirements for instructions.

Although in the example of instruction 200 of Figure 5A, the number of memory locations whose tags are to be queried may be explicitly set, in alternative embodiments the number may be implicit, and thus, for example, may be derived from thereon the nature of the equipment on which the instructions are executed. An example of such a command is illustrated in Figure 5B, which illustrates the "DC_CQueryTagsM" command 225. Operation code 230 identifies this command as a DC_CQueryTagsM command, while field 235 serves the same purpose as field 210 in command 200 of Figure 5A, and thus identifies the sequence of memory locations whose tag bits will be queried start address of . However, in this example, there is no separate field to identify the number of tags to query, but instead the number of tags accessed during a bulk query operation is based on the cache line of the associated data cache Length determination, such as level 1 data cache 36 shown in Figure 1 (the term "DC" as used in the command name is intended to convey this is a batch query command type where the number of query tags depends on the data cache Take the memory's cache line size). The cache line size may be specified, for example, in one of the system registers available to the processor (indicated by reference numeral 90 in FIG. 1).

In one embodiment, the start address specified in field 235 is aligned with the granularity of the cache line length and, therefore, with each block of data maintained in the cache line when the instruction is executed The associated tag bits are queried and sorted into an output value, which is then output to the general purpose register specified in field 240. Alternatively, if the start address specified in field 235 is not aligned with the granularity of the cache line length, then in an alternate embodiment the bit in the address that caused the address to be misaligned may be ignored, and the The address is effectively transformed into an aligned address.

Figures 6A and 6B illustrate two example ways in which the tag bits associated with each data block can be incorporated into each cache line in the data RAM (random access memory) of the data cache in the cache line information. In the example shown in FIG. 6A, data RAM 250 includes a plurality of cache lines 255, where each cache line accommodates a plurality of blocks of data (eg, shown in FIG. 3 by way of example) multiple 128-bit blocks). In the example shown in Figure 6A, each tag bit is appended to the end of each data block (or it may be pre-suspended at the beginning of each data block). Therefore, the effective length of the cache line is extended to incorporate the necessary tag bit information.

Although in the embodiment shown in FIG. 6A, the various tag bits are located with their corresponding data blocks, in the alternative example shown in FIG. 6B, the various tag bits are all accommodated in each cache memory of the data RAM 260 in the last portion 270 of the body line 265 . Thus, the data blocks in each cache line are appended one after the other, and the tag bit information is sorted at the end of the cache line (it should be appreciated that in an alternative embodiment it may be sorted in the cache at an appropriate point in the memory line, such as at the beginning of the cache line). It should be understood that Figures 6A and 6B are merely two exemplary arrangements by which the tag bit information may be accommodated in the cache line content, and that any other suitable scheme may be employed.

Although the instructions illustrated in Figures 5A and 5B are intended to operate on tag bits associated with a sequence of memory locations, the device may also support the execution of instructions that operate on capability registers to perform batch tag lookup operations . One such instruction is illustrated in Figure 7, and in particular specifies the instruction CQueryTagsR 300, which is arranged to perform a query on a plurality of tag bits related to a series of capability registers (with respect to which instructions are illustrated in relation to the CQueryTagsR 300). Figures 5A and 5B of memory location operations compared to the "M" term at the end of the instruction, where the "R" term at the end of the instruction indicates that it operates on the capability register).

Field 305 contains the operation code identifying the commands as CQueryTagsR commands. Field 310 is then used to identify the plurality of capability registers whose tag bits will be queried. The manner in which the plurality of capability registers are identified in field 310 may vary depending on the embodiment. For example, it may identify a general register of the plurality of registers to be queried by reference to its content or by an immediate value specifically incorporated in field 310 . In fact, a combination of general purpose registers and immediate values can be used to specify the registers to be queried.

Two example ways of identifying registers in field 310 are schematically illustrated in the lower half of FIG. 7 . In a first example, a mask value 320 is provided, which may be specified, for example, by the contents of a general register or by an immediate value. The mask value can be used to directly identify the register to be queried. For example, each bit of the mask value may correspond to a register in the register file, and whether that bit is set or cleared determines whether the register's tag bit will be queried. For example, each set bit may identify the register whose tag bit will be queried. If there are multiple separate scratchpad files in the device, an optional scratchpad file identifier 325 may be specified to identify the scratchpad file to which the mask value 320 is applied. It should be appreciated that by using such mask values, it is possible to specify any number of capability registers whose tag bits will be queried.

In an alternate arrangement, also shown in Figure 7, field 310 may actually incorporate two subfields, the first subfield 330 identifying the base register identifier, and the second subfield 335 Identify the count value. When combined, these fields can be used to identify a sequence of multiple registers starting with the register identified by the base register identifier. One of the subfields 330, 335 may use a generic register to identify its content, while the other subfield may, for example, provide an immediate value. Additionally, if multiple register files are provided in the device, an optional additional field 340 may be used to identify the particular register file on which the register will operate.

Like the commands of Figures 5A and 5B, the command 300 of Figure 7 includes a field 315 in which the general register to which the query results will be written is identified.

In the example of Figures 5A, 5B, and 7, the commands are batch query commands that cause a batch query operation to be performed to retrieve tag bits associated with multiple storage elements, and then output those tag bits meta for storage in the general purpose register. Another type of instruction that may be provided in the apparatus is a batch modification instruction which, when executed in the execution stage 12 in response to control signals generated by the decoding stage 8, causes the modification data to be modified according to the modification data specified by the batch modification instruction. Selectively modify the tag bits associated with each identified storage element.

Three such batch label modification instructions are illustrated in Figures 8A, 8B, and 8C, which generally correspond to the equivalent batches of Figures 5A, 5B, and 7, respectively query instruction.

In particular, Figure 8A illustrates a CModTagsM instruction 350, which may be used to perform a bulk tag modification operation on tag bits associated with a sequence of memory locations, wherein the number of memory locations and thus the tags to be manipulated are explicitly identified in the instruction. The number of bits. Operation code 355 thus identifies the command as a CModTagsM command, and fields 360, 365 generally correspond to fields 210, 215 of command 200 in Figure 5A. Therefore, these two fields together identify the start address and the number of tags to be modified. Field 370 then identifies the general register containing the modification data, and thus provides an indication of the updated tag value to be applied during the bulk tag modification operation. In more detail, the manner in which the specified bit in the general register identified in field 370 may be used to determine the tag bit modification to make will be discussed later with reference to FIG. 10 .

Figure 8B illustrates the format of the DC_CModTagsM instruction 375, which can again be used to perform bulk tag modifications on tag bits associated with a sequence of memory locations, but in this example the number of tag bits to operate on is determined by the device The nature of this implies, in particular, is implied by the cache line length of a cache line in one of the device's data caches. Operation code 380 identifies this instruction as a DC_CModTagsM instruction, and field 385 serves the same purpose as field 235 of instruction 225 of Figure 5B, and thus identifies the start address of the sequence of memory locations. Field 390 serves the same purpose as field 370, and thus identifies a general register whose contents identify how to update the label value during bulk label modification operations.

While the instructions of FIGS. 8A and 8B result in a batch tag modification operation on a sequence of memory locations, the instruction shown in FIG. 8C instead performs operations on a plurality of capability registers in the set of capability registers 60 . Associated tag bit operations. In particular, Figure 8C illustrates a CModTagsR instruction 400, where the operation code 405 identifies the instruction as a CModTagsR instruction. Field 410 serves the same purpose as field 310 of instruction 300 of FIG. 7, and thereby identifies the plurality of registers whose tag bits are to be subjected to bulk modification operations. Field 415 then identifies how the tag value is to be modified during the bulk tag modification operation. Although field 415 may only contain references to general registers in the same manner as fields 370, 390 of the instructions shown in Figures 8A and 8B, in alternate embodiments, field 415 may specify an immediate value , or a combination of immediate values and general purpose registers can be used to identify pending modifications. Although in principle the fields 370, 390 of the instructions shown in Figures 8A and 8B could also use a combination of general registers and immediate values to identify pending updates, it has been found that when executing on the contents of the capability register For bulk tag modification, the use of general purpose registers in combination with immediate values may be more useful, provided that the non-contiguous nature of the ability registers to undergo bulk tag modification operations can be specified.

The manner in which tag bits are stored in a generic register identified for query results when performing a bulk tag query operation or the manner in which the modified data bits are expressed in a generic register identified for bulk tag modification operations can take various forms . Figure 9A illustrates a compressed format where each bit starting with the least significant bit identifies either the tag bit being queried (when the register is used to accumulate the results of a batch tag query operation) or the individual item modification data (when The general purpose register is used as a source register to identify modification data used during bulk tag modification operations). Therefore, a sequence of bits 425 is provided in the general purpose register 420 . The number of significant bits in the register will depend on the number of storage elements whose tag bits are being queried or modified, and thus some of the more significant bits of register 420 may be unused. Although the compressed format is shown starting from the least significant bit position in Figure 9A, it should be understood that in alternative embodiments the compressed format may start from the most significant bit, and thus some number of least significant bits may not be available. in use.

Figure 9B illustrates an alternative approach, in which the general register 430 contains a sequence of information blocks, in this example a sequence of individual bytes, and a certain bit 435 in each byte is used to identify the queried tag One of the bits (in the instance of the bulk tag query operation) or one of the modification data (in the instance of the bulk tag modification operation). Other bits in each byte group may be used for other information, if desired, or may be unused.

FIG. 10 is a diagram illustrating in greater detail how modification data bits may be used to identify updates to individual tag bits during the execution of bulk tag modification operations. For illustration purposes, the compressed format of Figure 9A is shown, but the same principles apply to the uncompressed format of Figure 9B. Four example options for explaining the sequence of bits 425 are illustrated in FIG. 10 . Each bit 425 corresponds to one of the tag bits to be modified. According to option A, if bit 425 is at a logic 0 value, then the corresponding tag bit is cleared to identify that the associated data block does not indicate capability. Conversely, if bit 425 is at a logic 1 value, the corresponding tag bit is set to identify the ability to interpret the associated data block. In embodiments where the tag bits are set to a logic 1 value to identify the corresponding data block as capable, and cleared to a logic 0 value to identify the associated data block as incapable, then the update can be effectively performed via a move operation, thereby in During the batch tag update operation, the content of the relevant bit 425 in the register 420 is moved to the corresponding tag bit.

Option B illustrates the case where if bit 425 is at a logic 0 value, the corresponding tag bit remains unmodified. Therefore, if already set, the corresponding tag bit will remain in the set state, otherwise it will remain in the clear state. Conversely, if bit 425 has a logic one value, this will cause the tag bit to be cleared. In one embodiment, this option may be implemented via the use of a BIC (bit clear) operation.

According to option C, if bit 425 is at a logic 0 value, the corresponding label bit remains unmodified, and if bit 425 is at a logic 1 value, the label bit is set. In one embodiment this option may be implemented via the use of ORR operations.

Option D illustrates other options that can be used in principle if desired, but may have less practical application to modify the Capability Tag bits than the other options A to C. According to option D, if bit 425 has a logic 0 value, the corresponding label bit remains unmodified, and if bit 425 has a logic 1 value, the value of the corresponding label bit is swapped, and thus cleared if already set, and Set if cleared. In one embodiment this operation may be implemented by an exclusive OR (XOR) operation.

Although in one embodiment the execution of the batch labeling operation may be unconditional, in an alternative embodiment the apparatus may be arranged such that certain conditions must be satisfied before the batch labeling operation is allowed to proceed. FIG. 11 is a flow diagram illustrating an example implementation in which one or more checks are performed before the batch tag instruction is allowed to execute. In step 450, it is determined whether a batch label command has been received. At step 455, it is then determined whether the batch operations required to execute the specified instruction are permitted. In particular, as discussed below by way of example with reference to Figures 12A-12C, various restrictions may be set when at least some bulk tag instructions can be executed.

These restrictions may apply equally to all types of batch label commands, or more complex restrictions may be placed on the use of certain types of batch label commands. For example, in some embodiments, fairly strict restrictions may be placed on the use of batch tag modification instructions, while the use of batch tag query instructions may be less restricted. This is due to the fact that strict control over the ability to modify the tag bits associated with a block of data is often important, because if no such control is placed on the ability to transform generic data into capabilities, then capabilities based The security provided by the architecture can be potentially limited. In particular, the execution of bulk tag modification instructions is potentially a very powerful tool because it can enable multiple capabilities by setting tag bits in association with multiple data blocks.

If it is determined at step 455 that the batch operation required by the instruction is not allowed, then at step 465 it is determined that a fault condition has occurred. This may involve, for example, generating a processor fault by taking an exception.

If it is determined that the batch operations required by the instruction are permitted, any other required checks may be performed at step 460 as appropriate. For example, if a bounded pointer is used to identify the start address of a bulk tag operation performed on a sequence of memory locations, the range and permission attributes of the bounded pointer will be checked to ensure the sequence of memory locations identified by the bulk tag instruction Be within the allowable range and satisfy any permitted attributes. As another example of additional checks that may be performed at step 460, any memory management unit (MMU) access permissions may be checked to ensure that they are satisfied. Additional checks may be performed to ensure that no memory failures have occurred with respect to the determined memory address range. If no other required checks have been experienced, the process proceeds again to step 465 where a fault condition occurs. Otherwise, however, the process proceeds to step 470, where the batch operations required by the specified batch label instruction are performed.

Figures 12A-12C illustrate some example restrictions that may be placed on the use of batch label instructions, and in particular Figures 12A-12C each illustrate steps that may be taken to implement the steps of Figure 11 in different embodiments 455 steps. Considering first FIG. 12A, at step 500, the batch operation requested by the batch tag instruction is identified. Then, it is determined at step 505 whether the processor is operating in a predetermined elevated privilege state. The predetermined elevated privilege state may take various forms depending on the embodiment, but may be a hypervisor level considering, for example, a virtual machine type environment. If it is determined that the processor is not operating in a predetermined elevated privilege state, the process proceeds to step 515 where a fault occurs. Step 515 corresponds to step 465 in FIG. 11 . However, if the processor is in a predetermined elevated privilege state, the bulk operation is performed at step 510 subject to any additional checks that need to be performed, such as those previously discussed with reference to step 460 of FIG. 11 .

Figure 12B illustrates an alternative approach, where steps 520, 530, and 535 correspond to steps 500, 510, and 515 of Figure 12A, but where test 505 is replaced by test 525, and specifically determines whether a privileged configuration register has been set to allow the identified bulk operation to be performed. A privileged configuration register may, for example, be a register that can be set by a processor when operating in a predetermined privileged state, and thus its value can only be modified by a processor operating in the predetermined privileged state. Assuming the contents of the configuration register indicate that the identified bulk operation is allowed, the process proceeds to step 530 , otherwise, a fault occurs at step 535 .

As mentioned earlier, different limits can be set for different types of bulk label operations. Therefore, different privilege configuration registers, or different fields in the privilege configuration registers, can be used to identify permissions for different types of bulk operations. Thus, for example, one or more privileged configuration registers may identify that the bulk tag query operation is allowed, but the bulk tag modification operation is not allowed.

Figure 12C illustrates another alternative approach in which batch operation capabilities are defined. As previously mentioned, capabilities effectively identify a set of rights available to a processor, and while most capabilities can take the form of bounded pointers as previously described, not all capabilities need to be bounded pointers. Alternatively, the ability to identify certain rights only with respect to certain functionality may be defined. Thus, batch operation capabilities may be defined, which may be maintained, for example, in one of the capability registers 60, and specified as inputs to batch tag operations. Thus, in addition to specifying the various other operands discussed previously, a batch tag instruction may, for example, identify a batch operation capability as one of its operands. In such an arrangement, after step 540 of identifying the requested batch operation, the batch operation capability identified by the batch tag instruction is retrieved at step 545 from the associated capability register and then analyzed to determine its content. Then, at step 550, it is determined whether the batch operation capability allows execution of the identified batch operation. If so, the process proceeds to step 555, otherwise, a fault occurs at step 560.

The bulk operation capability may have a permission bit set to indicate whether any form of bulk tag operation is allowed, or alternatively may provide different permission bits for bulk tag modification and for bulk tag query operations.

The batch operation capability may also identify scope information that can be checked for batch tag operations to be performed on the sequence of memory locations, where if the scope information does not match, a fault is again generated at step 560 . However, in one embodiment, this range information is not required in the batch operation capability, and instead, when using the instruction format previously discussed with reference to Figure 5A, Figure 5B, Figure 8A, or Figure 8B, the capability is temporarily The register can be used to identify the starting address of the sequence of memory locations, and the range information of the capability register can be checked with respect to the portion of the subsequent step 460 of FIG. 11 .

As discussed previously, eg, with reference to Figure 3, as capabilities are moved between memory and the capability register, the tag bits move with the capabilities to identify that the associated data block is actually a capability. However, in some implementations it may be necessary to store capabilities from memory to backup storage such as disk, eg due to insufficient space to keep all capability information in memory, or when hibernation is supported. In one embodiment, this involves decomposing each capability into separate data and label parts, and handling the label as data in backup storage. This is schematically illustrated in Figure 13, where tag bits 615 follow each data block 610 as capabilities move between capability registers 600 and memory 605, following the approach previously described with reference to Figure 3. move. Thus, each data block in memory 605 can be identified as representing capability or general data. When the data block is moved to backup storage 625, then the decomposition process 620 is used to decompose the capability into data 624 and tag information 622, which is processed as data. Thus, in backup storage, the information persists only as data, and backup storage is capability insensitive.

When rebuilding capabilities from data stored in backup storage, a rebuilding process 630 needs to be performed, which may be limited to ensure that the security that can be obtained by using capabilities is not compromised. As discussed in greater detail below with reference to FIG. 15, the batch label modification instructions previously described may be used for this capability rebuilding purpose, and the use of such instructions may be limited by using the methodologies previously discussed with reference to FIG. 11 (eg, using Step 455 of Figure 11) is implemented using the techniques previously described with reference to Figures 12A-12C. Assuming the rebuild operation is determined to be executable when the rebuild operation 630 is requested, the capability may be rebuilt at step 630 and written back to the shared memory 605 (as discussed in more detail below, in one embodiment, using a capability register rebuild and then export the rebuild capability into shared memory 605).

Figure 14 is a flow chart illustrating the decomposition process, wherein the schematic diagram in the right hand side of Figure 14 further illustrates the process performed by the various steps shown in the flow chart.

At step 650, a batch tag query command is executed to aggregate tag values from multiple storage locations into a general-purpose register. Thus, as shown on the right-hand side of FIG. 14, for a contiguous sequence of memory locations in memory address space 665, the tag bits can be accessed and retrieved, and then sorted for storage in the general temporary storage in device 670.

Then, in step 655 , the contents of the general purpose register 670 are written out to the backup storage 675 . At this moment, the backup storage threat is only for general data and is capability-agnostic.

At step 660, a standard write operation is then used to write out to backup storage 675 each block of data in the sequence of memory locations whose associated tag bits were subjected to a bulk tag lookup operation at step 650. In one embodiment, the implementation would involve loading blocks of data from memory address space into a scratchpad, and then writing them out from scratchpad to backup storage.

FIG. 15 is a flowchart illustrating the rebuild operation 630 of FIG. 13, according to one embodiment. As in FIG. 14, the schematic diagram on the right-hand side of FIG. 15 illustrates the operations performed in each step of FIG. 15. FIG. At step 700, a series of load operations are used to load a plurality of data blocks from backup storage 720 into corresponding sets of capability registers in capability registers 725, wherein the corresponding capability registers are associated with each other. The tag bit is cleared to a logic 0 value to identify that the data block does not currently represent a capability.

Then at step 705, a load operation is used to load data representing a plurality of tag values (in particular tag values associated with each of the data blocks in the load capability register 725) from the backup store 720 into the general temporary store in device 730.

Then, at step 710, a batch label modification process is performed, such as by executing the batch label modification instruction previously discussed with reference to FIG. 8C, wherein the identified capability register is the associated capability from the set of capability registers 725 scratchpad. The instruction also identifies the general purpose register 730 as containing modification data used during batch tag modification operations. As discussed previously with respect to FIG. 11, one or more checks may be performed during execution of step 710 to check that the identified bulk label modification operations are permitted. However, assuming they are checked, performing the bulk tag modification operation at step 710 will result in modification of tag values associated with each of the associated capability registers 725 depending on the data held in the general register 730. This may result in multiple data blocks being identified as capabilities (in one embodiment, all data blocks may have their tag bits set to identify their equivalent capabilities). Thus, during execution of step 710, capabilities are effectively regenerated based on information that has been retrieved from backup storage 720. Then, at step 715 , the capability register contents and its associated tag bits may be moved to memory address space 735 .

Although in the embodiment discussed with reference to FIG. 15, the modification data used to update the tags is first stored in the general register 730, in alternate embodiments, the batch tag modification operation may be modified such that tag values may be changed from The memory is loaded directly into the relevant capability register tag location. In a similar fashion, operations may be provided to store capability tag information directly into memory as generic data blocks from the capability register (without using an intermediate generic register).

Figure 16 illustrates an alternative embodiment in which instead of having the processor core execute bulk tag instructions to perform bulk tag query or bulk tag modification operations, the processor core is enabled to offload this task to the associated DMA circuitry. Specifically, as shown in FIG. 16, processor pipeline 750 is connected to one or more stages of cache memory 760 via memory management unit 755, and then to memory 770 via interconnect 765. The MMU 755 may incorporate the TLB structure 52 previously discussed with reference to FIG. 1, and thereby translate virtual addresses issued by the processor pipeline to physical addresses forwarded onto the cache/memory system. According to this embodiment, when the processor pipeline desires to perform a bulk tag query or modification operation, it can issue the appropriate request to the DMA circuitry 775 via the dotted path 780, providing sufficient information to enable the DMA circuitry to identify the required The operation type and its tag bits are subject to a sequence of memory addresses for bulk tag operations. The DMA circuitry then issues a sequence of transactions 780 via interconnect 765 to memory system 770 to perform bulk tag query or modification operations. Each transaction will involve issuing a request from DMA circuitry to memory, and at least one reply from memory 770 back to DMA circuitry 775 . For batch label query operations, the response can incorporate the queried label information. For bulk tag modification operations, the request issued by the DMA circuit will be accompanied by the necessary modification data needed to update the tag bits in memory, and the response will take the form of an acknowledgment signal from the memory system confirming that the modification has been performed.

According to this embodiment, the bulk tag query/modify operation is expressed at the bus protocol level, enabling a bus master such as DMA circuit 775 to perform this operation on behalf of processor pipeline 750 .

Figure 17 illustrates a virtual machine implementation that may be used. While the previously described embodiments implement the technology in terms of apparatus and methods for operating specific processing hardware supporting the related art, it is also possible to provide so-called virtual machine implementations of hardware components. These virtual machine implementations run on a host processor 830 , which typically runs a host operating system 820 that supports virtual machine programs 810 . In general, a large, efficient processor is required to provide a virtual machine implementation that executes at reasonable speed, but this approach may be reasonable in certain environments, such as when another processor-native code needs to be run for compatibility , or for reuse reasons. The virtual machine program 810 provides the guest program 800 with a virtual hardware interface that is the same as the hardware interface provided by the actual hardware through the components modeled by the virtual machine program 810 . Thus, program instructions, including the batch tag/batch capability metadata instructions described above, may be executed in guest program 800 using virtual machine program 810 to model the interaction of the instructions with the virtual machine hardware. Guest program 800 may be a bare metal program, or alternatively it may be a guest operating system that runs applications in a similar manner to how main OS 820 runs virtual machine applications 810 . It should also be understood that there are different types of virtual machines, and in some types, the virtual machine runs directly on the host hardware 830 without the host OS 820.

From the embodiments described above, it should be appreciated that these embodiments enable better access to capability metadata, such as tag bits in the capability schema. The described operations can be used in a variety of situations, such as when paging memory from backup storage to tagged memory locations or from those tagged memory locations to backup storage, or when paging across storage systems that lack inherent capability support. When moving a virtual machine over the network. The described embodiments provide several instructions executable to allow batch query or manipulation of a range of capability locations. Describes two different groups of instructions, one group that batches operations to capability memory locations and the other that batches operations to capability register locations.

In this application, the term "configured to..." is used to mean that an element of equipment has a configuration capable of performing the defined operation. In this context, "configuration" means the interconnection arrangement or manner of hardware or software. For example, a device may have dedicated hardware that provides the defined operation, or a processor or other processing element may be programmed to perform the function. "Configured to" does not imply that the device element needs to be changed in any way to provide defined operation.

Although illustrative embodiments 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 may be effected in the invention by those skilled in the art , without departing from the scope and spirit of the invention as defined by the appended claims. For example, the features of the dependent item may be combined with the features of the independent item in various combinations without departing from the scope of the present invention.

2‧‧‧Data processing equipment 4‧‧‧Processing pipeline 6‧‧‧Capture stage 8‧‧‧Decoding stage 10‧‧‧Publish stage 12‧‧‧Execution stage 14‧‧‧Write back stage 20‧‧‧1 Level Instruction Cache 22‧‧‧Branch Predictor 24‧‧‧Branch Target Location Cache 30‧‧‧Execution Unit 32‧‧‧Execution Unit 34‧‧‧Execution Unit 36‧‧‧Level 1 Data Cache Fetch Memory 40‧‧‧Register 44‧‧‧Level 2 Cache 50‧‧‧Main Memory 52‧‧‧Translation Lookaside Buffer 60‧‧‧Bounded Pointer Register 62‧‧‧Pointer Value 64‧‧‧Range Information 66‧‧‧Limit Information 68‧‧‧Boundary 69‧‧‧Boundary 80‧‧‧Program Counter Capability Register 82‧‧‧Field 84‧‧‧Range Information 86‧‧‧Limit Information 90‧‧‧Component Digital 100‧‧‧Capability Register 102‧‧‧Pointer 104‧‧‧Range Information 106‧‧‧Restriction Information 108‧‧‧Label Bit 110‧‧‧Memory Address Space 115‧‧ ‧Data Block 120‧‧‧Label Field 150‧‧‧Capability 155‧‧‧Capability Metadata 160‧‧‧Pointer Value 165‧‧‧Scope Information 170‧‧‧Permission Attribute 200‧‧‧Directive 205‧‧Operation Code Field 210‧‧‧Field 215‧‧‧Field 220‧‧‧Field 225‧‧‧Command 230‧‧‧Operation Code 235‧‧‧Field 240‧‧‧Field 250‧‧‧Data RAM255 ‧‧‧Cache Line 260‧‧‧Data RAM265‧‧‧Cache Line 270‧‧‧Last Part 300‧‧‧Command CQueryTagsR305‧‧‧Field 310‧‧‧Field 315‧‧‧Field Bit 320‧‧‧Mask Value 325‧‧‧Register File Identifier 330‧‧‧First Subfield 335‧‧‧Second Subfield 340‧‧‧Other Fields 350‧‧‧CModTagsM Command 355 ‧‧‧Operation Code 360‧‧‧Field 365‧‧‧Field 370‧‧‧Field 375‧‧‧DC_CModTagsM Command 380‧‧‧Operation Code 385‧‧‧Field 390‧‧‧Field 400‧‧ ‧CModTagsR Command 405‧‧‧Operation Code 410‧‧‧Field 415‧‧‧Field 420‧‧‧Register 425‧‧‧Bit 430‧‧‧General Register 435‧‧‧Bit 450‧ ‧‧STEP 455‧‧‧STEP 460‧‧‧STEP 465‧‧‧STEP 470‧‧‧STEP 500‧‧‧STEP 505‧‧‧STEP 510‧‧‧STEP 515‧‧‧STEP 520‧‧‧STEP 525‧ ‧‧Test 530‧‧‧Step 535‧‧‧Step 540‧‧‧Step 545‧‧‧Step 550‧‧‧Step 555‧‧‧Step 560‧‧‧Step 600‧‧‧Capability Register 605‧‧‧ Memory 610‧‧‧Data Block 615‧‧‧Label Bit 620‧‧‧ Decomposition Process 622‧‧‧Label Information 624‧‧‧Data 625‧‧‧Backup Storage 630‧‧‧Rebuilding Process 650‧‧‧Step 655‧‧‧Step 660‧‧‧Step 665‧‧‧Memory Address Space 670‧ ‧‧General Register 675‧‧‧Backup Storage 700‧‧‧Step 705‧‧‧Step 710‧‧‧Step 715‧‧‧Step 720‧‧‧Backup Storage 725‧‧‧Capability Register 730‧‧‧ General Purpose Register 735‧‧‧Memory Address Space 750‧‧‧Processor Pipeline 755‧‧‧Memory Management Unit 760‧‧‧Cache Memory 765‧‧‧Interconnect 770‧‧‧Memory 775‧ ‧‧DMA Circuitry 780‧‧‧Dot-Line Path 800‧‧‧Guest 810‧‧‧Virtual Machine 820‧‧‧Main Operating System 830‧‧‧Main Processor

The present technology will be further described, by way of example only, with reference to the embodiments of the present disclosure as illustrated in the accompanying drawings, wherein:

Figure 1 is a block diagram of an apparatus according to one embodiment;

Figure 2 illustrates an example of the type of instruction for which an attempt to set or access a pointer value in the set of bounded pointer storage elements, where the pointer value is used to specify the range information specified in the set of bounded pointer storage elements, can trigger an error address outside the indicated range;

Figure 3 illustrates the use of tag bits associated with bounded pointers, according to one embodiment;

Figure 4 schematically illustrates various fields and related capability metadata information provided in capabilities in the form of bounded pointers, according to one embodiment;

Figures 5A and 5B illustrate fields provided in two different instructions that may be provided in accordance with one embodiment to perform bulk tag lookup operations on storage elements in memory;

Figures 6A and 6B illustrate how tag bits (an example of capability metadata) may be stored in a cache line of cache in association with each data block, according to two different embodiments;

Figure 7 schematically illustrates fields provided in an instruction to perform a bulk tag query operation on storage elements in the form of capability registers in the device, according to one embodiment;

Figures 8A and 8B illustrate fields provided in two different forms of instructions that may be used, according to one embodiment, to perform bulk tag modification on storage elements in memory that take the form of memory locations operation, and Figure 8C illustrates the fields provided in the instruction that may be used, according to one embodiment, to perform bulk tag modification operations on storage elements in the form of capability registers;

Figures 9A and 9B illustrate different ways in which a general purpose register may be populated to hold queried tag values obtained by performing bulk tag query operations or tags applied during bulk tag modification operations, according to one embodiment an indication of the value;

Figure 10 schematically illustrates four examples of how information within a general purpose register such as that illustrated in Figure 9A may be interpreted during the execution of a bulk tag modification operation, according to one embodiment;

FIG. 11 is a flow diagram illustrating a process, in one embodiment, executable by processing circuitry to determine whether a batch tag operation specified by a batch tag instruction is permitted, according to one embodiment;

FIGS. 12A-12C are flowcharts illustrating steps that may be executed to implement step 455 of FIG. 11 according to one embodiment;

Figure 13 schematically illustrates a decomposition process and a rebuild process with respect to capabilities transferred between capability-aware storage elements and capability-agnostic backup storage, according to one embodiment;

FIG. 14 is a flow diagram schematically illustrating the decomposition process of FIG. 13, according to one embodiment;

FIG. 15 is a flow diagram schematically illustrating the capability rebuilding process of FIG. 13, according to one embodiment;

FIG. 16 is an apparatus according to an alternative embodiment, wherein the processor pipeline offloads bulk tag query or modification operations to DMA circuitry, causing the DMA circuitry to perform the bulk tag query or modification operations via a series of transactions; and

Figure 17 schematically illustrates a virtual machine implementation of a device according to one embodiment.

Domestic storage information (please note in the order of storage institution, date and number) None

Foreign deposit information (please note in the order of deposit country, institution, date and number) None

(Please change the page and record it separately) None

150‧‧‧Ability

155‧‧‧Ability Metadata

160‧‧‧Pointer value

165‧‧‧Scope Information

170‧‧‧License Properties

Claims (27)

A device for performing operations on capability metadata, comprising: a storage element for storing data blocks, each data block has capability metadata associated with it to identify whether the data block specifies a capability, and at least one capability type is a bounded pointer ; and processing circuitry responsive to identifying a bulk capability metadata operation for a plurality of the storage elements to perform an operation on the capability metadata associated with each block of data stored in the plurality of storage elements, wherein the The batch capability metadata operation is one of: a batch query operation, and the processing circuitry responds to the batch query operation to obtain the capability associated with each data block stored in the plurality of the storage elements metadata, and used to generate output data containing the obtained capability metadata, and a batch modification operation, and the processing circuitry is responsive to the batch modification operation to modify depending on the modification data specified for the batch modification operation the capability metadata associated with each data block stored in the plurality of the storage elements. The apparatus of claim 1, wherein the bulk modify operation results in setting the capability metadata associated with each data block stored in the plurality of the storage elements to identify each data block specifying a capability. The apparatus of claim 1, wherein the bulk modify operation results in clearing the capability metadata associated with each data block stored in the plurality of the storage elements to identify each data block specifying data other than a capability. The apparatus of claim 1, wherein for each capability metadata to be accessed by the bulk modification operation, the modification data identifies the modification performed with respect to the capability metadata. The apparatus of claim 4, wherein the modification data provides a modification value for each capability metadata accessed by the bulk modification operation, the value identifying at least one of two of the following modifications: (i) setting the capability metadata to identify the associated data block specifying a capability; (ii) clear the capability metadata to identify the associated data block specifying data other than a capability; and (iii) leave the capability metadata unchanged. The apparatus of claim 1, wherein the processing circuitry is arranged to perform the batch capability metadata operation satisfying a condition. The apparatus of claim 6, wherein the condition is determined to be satisfied if at least one of the following conditions is true: (i) the processing circuitry operates in a predetermined privileged state; (ii) a configuration storage element may be set to have a value indicating that the batch capability metadata operation is permitted when the processing circuitry operates in a predetermined privileged state; (iii) a request for specifying the batch capability metadata operation A bulk operation capability is identified, and the bulk operation capability indicates that the bulk capability metadata operation is allowed. The apparatus of claim 1, wherein the storage elements are memory locations. 8. The apparatus of claim 8, wherein the plurality of memory locations are defined with reference to a bounded pointer, and the processing circuitry is arranged to, when determining that the plurality of memory locations reside in the one identified by the bounded pointer Perform this bulk capability metadata operation when the allowable address range is within the range. The apparatus of claim 1, wherein the storage elements are capability registers accessible by the processing circuitry. The apparatus of claim 1, further comprising: decoding circuitry responsive to an instruction sequence to generate control signals for issuing to the processing circuitry to cause the processing circuitry to perform operations required by the instruction sequence; the Decoding circuitry generates control signals in response to receiving a batch capability metadata instruction, the control signals for issuing to the processing circuitry to cause the processing circuitry to execute the batch capability metadata instruction Make the required batch capability metadata operations. The apparatus of claim 11, wherein the storage elements are memory locations and the batch capability metadata instruction specifies a register that provides identification that its associated capability metadata is subject to the batch capability metadata operation An address of a contiguous series of memory locations. The apparatus of claim 12, wherein the batch capability metadata instruction includes a field identifying a number of memory locations in the consecutive series. The apparatus of claim 13, wherein the field provides a reference to a register containing a value indicating the number of memory locations in the successive series and indicates the memory in the successive series One of an immediate value of this quantity of positions. The apparatus of claim 12, wherein a number of memory locations in the consecutive series is implied by a property of the apparatus. The apparatus of claim 15, wherein the property is a cache line length of a cache accessible by the processing circuitry. The apparatus of claim 11, wherein the storage elements are capability registers, and the bulk capability metadata instruction includes identification of the capability registers whose associated capability metadata is subject to the bulk capability metadata operation A register identifier field that identifies the register The identifier field provides at least one of an immediate value and a register identifier to identify the capability registers. The apparatus of claim 17, wherein the register identifier field provides one of the following: a mask value to identify the capability registers; a base identifier and a count value used in combination to Identify these capability registers. The apparatus of claim 1, further comprising: decoding circuitry responsive to a sequence of instructions to generate control signals for issuing to the processing circuitry necessary to cause the processing circuitry to execute the sequence of instructions operation; the decoding circuitry, in response to receiving a batch capability metadata command, generates control signals for issuing to the processing circuitry necessary to cause the processing circuitry to execute the batch capability metadata command the batch capability metadata operation, wherein: the batch capability metadata instruction is a batch query command, and the processing circuitry is arranged to respond to the control signals generated by the decoding circuitry when decoding the batch query command performing a batch query operation; the batch query command identifies a destination register, and the processing circuitry responds to the batch query operation to obtain the capability element associated with each data block stored in the plurality of the storage elements material, and used to generate output data containing the acquired capability metadata for storage in the destination register. The apparatus of claim 1, further comprising: decoding circuitry responsive to a sequence of instructions to generate control signals for issuing to the processing circuitry to cause the processing circuitry to execute the sequence of instructions required operations; the decoding circuitry, in response to receiving a batch capability metadata command, generates control signals for issuing to the processing circuitry required for the processing circuitry to execute the batch capability metadata command the bulk capability metadata operation, wherein: the bulk capability metadata instruction is a bulk modification instruction and the processing circuitry is arranged to respond to the control signals generated by the decoding circuitry when decoding the bulk modification instruction performing a bulk modification operation; the bulk modification instruction identifies a source field for identifying modification data, and the processing circuitry is responsive to the bulk modification operation to modify and modify data dependent upon the modification data identified by the source field the capability metadata associated with each data block stored in the plurality of the storage elements. The apparatus of claim 20, wherein the source field provides at least one of an immediate value and a register identifier to identify the modified data. The apparatus of claim 1, wherein the processing circuitry is arranged to perform a bulk query operation as the bulk capability metadata operation to obtain the data associated with each data block stored in the plurality of the storage elements capability metadata, the processing circuitry is further arranged to output data containing the acquired capability metadata for storage in a capability agnostic storage element. 2. The apparatus of claim 1, wherein the processing circuitry is arranged to perform a bulk modification operation as the bulk capability metadata operation to modify and store in dependent modification data obtained from a capability agnostic storage element The capability metadata associated with each data block in the plurality of the storage elements. The apparatus of claim 1, wherein: the processing circuitry is a direct memory access (DMA) circuit; and the batch capability metadata operation is specified by a processor core and causes the DMA circuit to issue one or more A transaction performs the batch-capable metadata operation on a pair-sequential series of memory locations. A method of performing operations on capability metadata, comprising the steps of: storing data blocks in a storage element, each data block having capability metadata associated therewith identifying whether the data block specifies a capability, at least one capability type having a bounds pointer; and in response to a batch capability metadata operation identifying a plurality of the storage elements, causing processing circuitry to perform an operation on the capability metadata associated with each block of data stored in the plurality of storage elements, wherein the batch capability metadata The operation is one of: a bulk query operation, wherein the processing circuitry responds to the bulk query operation to obtain the capability metadata associated with each data block stored in the plurality of the storage elements, and to generate output data containing the obtained capability metadata, and a bulk modification operation, wherein the processing circuitry is responsive to the bulk modification operation to modify and store in the bulk modification operation dependent modification data specified for the bulk modification operation the capability metadata associated with each data block in the plurality of the storage elements. A device for performing operations on capability metadata, comprising: a storage element component for storing data blocks, each data block having capability metadata associated with it identifying whether the data block specifies a capability, and at least one capability type is a bounded a pointer; and a processing means for performing an operation on the capability metadata associated with each data block stored in the plurality of storage element means in response to identifying a bulk capability metadata operation of the plurality of the storage element means, wherein The bulk capability metadata operation is one of the following: a bulk query operation, and the processing component is responsive to the bulk query operation to obtain the capability metadata associated with each data block stored in the plurality of the storage element components, and to generate the capabilities containing the obtained capabilities output data of metadata, and a bulk modification operation, and the processing element is responsive to the bulk modification operation to modify and store each of the plurality of the storage element elements depending on modification data specified for the bulk modification operation The metadata for this capability associated with the data block. A computer program product storing a computer program in a non-transitory form for controlling a computer to provide a virtual machine execution environment for program instructions corresponding to the apparatus of claim 1.

Images