Patent Description:
<CIT> describes protected guests in a hypervisor controlled system.

<CIT> describes a convolutional memory integrity.

<CIT> describes a method to provide secure application execution.

Various embodiments are generally directed to techniques for dynamic resource allocation among cryptographic domains, such as with memory pages in a platform that implements a plurality of cryptographically isolated domains, for instance. Some embodiments are particularly directed to a platform that includes a resource allocation manager (RMGR) that allows for page reassignment among cryptographically isolated virtual machines (VMs) while ensuring functional correctness with respect to integrity. In many embodiments, the RMGR may include hardware and/or software support for a new instruction that enables efficient key reassignment for memory pages. In some embodiments, the RMGR may be included in or implemented by a virtual machine monitor (VMM). In one embodiment, for example, an apparatus for resource allocation management may comprise logic with at least a portion of the logic implemented in circuitry. In various embodiments, the logic may identify a first key identifier associated with a first VM, and second key identifier associated with a second VM, and an address of a memory page allocated to the first VM. In various such embodiments, the logic may invalidate a cache line associated with the first VM based on the first key identifier. In some embodiments, the logic may generate a message authentication code (MAC) for the memory page based on the second key identifier. In various embodiments, a MAC may be associated with each cache line on the page. In many embodiments, the logic may allocate the memory page to the second VM. These and other embodiments are described and claimed.

Some challenges facing resource allocation include the inability or use of excessively complex, bulky, and inefficient techniques to reallocate resources from a first cryptographic domain to a second cryptographic domain. These challenges may result from the need to be able to reassign physical memory pages to meet memory demands of a workload or the need to switch allocation of a physical memory page from one workload to another workload, such as when the workload exits. For instance, cloud service providers may need to provide cryptographic isolation for different customer workloads running on a platform. Typically, a page reassignment between domains involves a key reassignment. Some systems, to avoid information leaks and avoid corruption of data, must follow a high-performance overhead flow on key reassignment. For example, this may include flushing or invalidating cache lines associated with the previous key assignment from a cache hierarchy and writing all zeroes to the page with the new key. Additionally, systems may only be able to perform flushes or invalidations at impractical granularities. This may involve having to flush cache lines individually (e.g., with CLFLUSH) or writing-back and invalidating all modified lines in a cache hierarchy (e.g., with WBINVD), resulting in excessive performance overhead. Therefore, in some instances, each key reassignment for a <NUM> kilobyte (KB) page may involve <NUM> cache line flush operations and <NUM> write operations.

Adding further complexity, ensuring integrity for each domain may lead to functional problems with respect to key reassignment. For instance, to reassign a page from a first workload using a first key to a second workload using a second key may require that the integrity values (e.g., MACs) associated with the page are reinitialized with the second key to avoid integrity failures. However, a write to memory attempting to update the integrity values, such as by zeroing out the page with the second key, can first result in a read for ownership. The read for ownership, using the second key, can fetch a cache line and the associated integrity values that were generated with the first key. This can lead to a verification failure because integrity values generated with the first key cannot be verified with the second key. These and other factors may result in resource allocation with deficient performance and an inability to ensure integrity between different cryptographic domains (also referred to simply as domains). Such limitations can drastically reduce the capabilities, usability, and applicability of platforms that support multiple cryptographic domains, contributing to inefficient systems with limited capabilities.

Various embodiments described herein include a platform that includes a resource allocation manager (RMGR) that allows for page reassignment among different domains, such as cryptographically isolated virtual machines (VMs), while ensuring functional correctness with respect to integrity. In many embodiments, the RMGR may include hardware support for a new instruction, referred to as PGINVDREMAP, that enables efficient key reassignment for memory pages being reallocated from a first domain to a second domain. In many such embodiments, the RMGR may include and/or utilize software support to implement PGINVDREMAP.

In one or more embodiments, PGINVDREMAP may operate at a preferred granularity, such as a page granularity. In one or more such embodiments, PGINVDREMAP may cause non-temporal writes to occur at the preferred granularity. In various embodiments, a non-temporal write may include or refer to a write without a preceding memory read, such as a write-for-ownership or direct store. In some embodiments, PGINVDREMAP may invalidate all cache lines associated with a page using an old key associated with the domain the page is being reassigned from. In various embodiments, PGINVDREMAP may also reinitialize integrity values (e.g., MACs) using a new key associated with the domain the page is being reassigned to. In various such embodiments, reinitialization of the integrity values may prevent integrity failures when the page is reassigned and used with the new key. In many embodiments, non-temporal writes may be used for reinitializing integrity values to enable integrity support for VM isolation. In these and other ways the RMGR may enable quick and efficient resource allocation/reallocation to achieve improved performance with reduced overhead, resulting in several technical effects and advantages. For example, the technical effects and advantages may include previously unattainable performance and/or security guarantees, such as with respect to VM isolation.

With general reference to notations and nomenclature used herein, one or more portions of the detailed description which follows may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substances of their work to others skilled in the art. A procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.

Further, these manipulations are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. However, no such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein that form part of one or more embodiments. Rather, these operations are machine operations. Useful machines for performing operations of various embodiments include general purpose digital computers as selectively activated or configured by a computer program stored within that is written in accordance with the teachings herein, and/or include apparatus specially constructed for the required purpose. Various embodiments also relate to apparatus or systems for performing these operations. These apparatuses may be specially constructed for the required purpose or may include a general-purpose computer. The required structure for a variety of these machines will be apparent from the description given.

Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the novel embodiments can be practiced without these specific details. In other instances, well known structures and devices are shown in block diagram form to facilitate a description thereof. The intention is to cover all modification, equivalents, and alternatives within the scope of the claims.

<FIG> and <FIG> illustrates an example of an operating environment <NUM> that may be representative of various embodiments. Operating environment <NUM> may include a platform <NUM>. In operating environment <NUM>, platform <NUM> may selectively implement one or more virtual machines (VMs) <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> in respective cryptographic domains <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-n. In some embodiments, multiple VMs maybe implemented within a cryptographic domain. In many embodiments, different cryptographic domains may be provided to different customers of a provider, such as a cloud service provider. In one or more embodiments described herein, resource allocation manager (RMGR) <NUM> may dynamically allocate/reallocate one or more hardware resources <NUM> among the domains <NUM> while maintaining confidentiality and/or integrity between cryptographic domains <NUM>. In one or more such embodiments, resource allocation may depend on a workload placed on respective VMs <NUM> in the cryptographic domains <NUM>, such as by a customer associated with the corresponding cryptographic domain. In various embodiments, each cryptographic domain <NUM> may correspond to a unique one or set of domain keys <NUM>. For example, hardware resources <NUM> may include memory that is encrypted/decrypted with a domain key that corresponds to the cryptographic domain that the memory has been allocated to. In many embodiments, RMGR <NUM> may update memory mappings <NUM> as part of allocating or reallocating one or more of the hardware resources <NUM>. In some embodiments, RMGR <NUM> may be implemented by or comprised in a virtual machine monitor (VMM). Embodiments are not limited in this context.

As illustrated in <FIG>, hardware resources <NUM> may include processing chip <NUM>, main memory <NUM>, and secondary memory <NUM>. In various embodiments, processing chip <NUM> may include processing cores <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-n with respective core caches <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-n and a shared cache <NUM>. In various such embodiments, the core caches <NUM> may be above the shared cache <NUM> in a cache hierarchy of the platform <NUM>. In many embodiments, main memory <NUM> may include memory pages <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-n which can each be dynamically allocated/reallocated among cryptographic domains <NUM>, such as by RMGR <NUM>. For example, RMGR <NUM> may allocate memory page <NUM>-<NUM> to domain <NUM>-<NUM> for use by VM <NUM>-<NUM>, memory page <NUM>-<NUM> to domain <NUM>-<NUM> for use by VM <NUM>-<NUM>, and memory page <NUM>-n to domain <NUM>-n for use by VM <NUM>-n. In one or more embodiments, main memory <NUM> may include random access memory. In some embodiments, the memory pages may be allocated/reallocated to specific VMs within the cryptographic domains. For instance, in various embodiments, multiple VMs may be instantiated in a cryptographic domain, and separate memory pages may be allocated to each VM.

In various embodiments, secondary memory <NUM> may include cryptographic domain storages <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-n. In various such embodiments, each of the cryptographic domain storages <NUM> in secondary memory <NUM> may correspond to one of cryptographic domains <NUM>. For example, cryptographic domain storage <NUM>-<NUM> may correspond to cryptographic domain <NUM>-<NUM>, cryptographic domain storage <NUM>-<NUM> may correspond to cryptographic domain <NUM>-<NUM>, and cryptographic domain storage <NUM>-n may correspond to cryptographic domain <NUM>-n. In such examples, each of the cryptographic domains storages <NUM> may be encrypted/decrypted with a corresponding domain key of domain keys <NUM>. In some embodiments, secondary memory <NUM> may include disk memory.

In one or more embodiments described herein, reallocating a memory page from a first domain to a second domain may include one or more of the following operations described with respect to reallocating memory page <NUM>-n from cryptographic domain <NUM>-<NUM> associated with a first key in domain keys <NUM> to cryptographic domain <NUM>-<NUM> associated with a second key in domain keys <NUM>. In some embodiments, the memory page <NUM>-n may be made inaccessible to components of cryptographic domain <NUM>-<NUM> including VM <NUM>-<NUM>. For example, RMGR <NUM> may invalidate all page mappings associated with memory page <NUM>-n in memory mappings <NUM>. In various embodiments, the contents of memory page <NUM>-n may be read and saved to a cryptographic domain storage <NUM>-<NUM> in secondary memory <NUM>. In various such embodiments, the contents of memory page <NUM>-n may be encrypted with the first key prior to being stored to secondary memory <NUM>.

In many embodiments, once the memory page <NUM>-n has been made inaccessible to cryptographic domain <NUM>-<NUM> and/or the page mappings have been invalidated, a new instruction, referred to as PGINVDREMAP, may be used to efficiently reassign keys for memory pages being reallocated from a first cryptographic domain to a second cryptographic domain. In one or more embodiments described herein, the PGINVDREMAP instruction flow may be summarized as follows: (<NUM>) send invd_page to all cores to invalidate all cache lines associated with a page being reassigned from an old cryptographic domain; (<NUM>) wait for acknowledgement from each of the cores that the invalidation of cache lines associated with the page being reassigned is complete; and (<NUM>) non-temporal writes to the entire page with a new key or key identifier associated with a new cryptographic domain the page is being reassigned to reinitialize the integrity values (e.g., MACs) with the new key or key identifier.

In many such embodiments, PGINVDREMAP may invalidate all cache lines in core caches <NUM> and shared cache <NUM> associated with memory page <NUM>-n using the first key, or an indication of the first key (e.g., key identifier). In some embodiments, PGINVDREMAP may be an instruction set architecture (ISA) instruction and/or a ring-<NUM> instruction. For instance, PGINVDREMAP may issue a command to each of processing cores <NUM> to invalidate cache lines associated with the cryptographic domain <NUM>-<NUM>. In various embodiments, PGINVDREMAP may also reinitialize integrity values (e.g., MACs) using the second key, which is associated with cryptographic domain <NUM>-<NUM>. In various such embodiments, reinitialization of the integrity values may prevent integrity failures when the page is reassigned and used with the second key. In several embodiments, a MAC may be associated with each cache line associated with or on a page. In many embodiments, non-temporal writes may be used for reinitializing integrity values to enable integrity support for VM isolation. In many embodiments, the RMGR <NUM> may include or utilize hardware and/or software support to implement PGINVDREMAP.

In some embodiments, such as when a VM may execute PGINVDREMAP to initialize its own or assigned memory. In such embodiments, the VM monitor (VMM) may be able to verify/determine one or more of (<NUM>) the instruction was executed by the processor; (<NUM>) which memory address the PGINVDREMAP was executed against; and (<NUM>) which key identifier the memory was initialized to or with. For instance, this could be enabled by the VMM configuring a VM execution control to trigger or a VM exit, or other invocation of the VMM after the PGINVDREMAP instruction was executed by the guest VM. In such instances, the VM control structure (VMCS), or similar, may contain the instruction identifier, address, and key identifier allowing the VMM to read this structure and verify the instruction was executed correctly by the VM as expected by the VMM. In various instances, after verifying correct execution of the instruction the VMM may then resume the VM. In some embodiments, these or similar techniques may be used to enable various usages, such as a secure public cloud usage.

In some embodiments, such as when VM memory is to be kept private from the VMM, a VM may be assigned an exclusive key (or set of keys) and associated key identifiers by the processor or hardware subsystem that only the VM may use while it is executing. In such embodiments, the PGINVDREMAP instruction may be executed by the VM for only the key identifier (or identifiers) which the VM was assigned by the processor or hardware subsystem. Accordingly, if a VM attempts to initialize memory using a key identifier not assigned to it by the processor, attempted execution of PGINVDREMAP may cause a fault, exit, or other error, and reinitialization will fail. PGINVDREMAP will be discussed in more detail below, such as with respect to <FIG>.

It will be appreciated that one or more keys described herein may refer to a key pair and one or more of the keys may undergo one or more key expansions to enable cryptographic operations. In one embodiment, for instance, before a key can be used for cryptographic operations, such as encrypting or generating MACs, it must be expanded into a larger number of keys. In some such instances the key may be expanded into <NUM> keys to support multiple rounds of encryption or decryption. In various embodiments, the key may be expanded on the fly during execution. In other embodiments, the keys may be expanded and stored prior to operation. In some embodiments, whether keys are expanded on the fly may be decided based on different performance constraints, such as area/performance tradeoffs.

<FIG>, <FIG>, and <FIG> illustrate an example of an operating environment <NUM> that may be representative of a first resource utilization among cryptographic domains <NUM>. <FIG>, <FIG>, and <FIG> illustrate an example of an operating environment <NUM> that may be representative of a second resource utilization among cryptographic domains <NUM>. Accordingly, a transition from a first resource allocation that corresponds with the first resource utilization to a second resource allocation that corresponds with the second resource utilization will be described with respect to <FIG>, <FIG>, and <FIG>. In many embodiments, the components of <FIG>, <FIG>, and <FIG> may be the same or similar to the components of <FIG> and <FIG>. Embodiments are not limited in this context.

In operating environment <NUM>, cryptographic domain <NUM>-<NUM> may be active with instantiated VM <NUM>-<NUM>, cryptographic domain <NUM>-<NUM> may be inactive without an instantiated VM, and cryptographic domain <NUM>-n may be active with instantiated VM <NUM>-n. As shown in <FIG>, each of the cryptographic domains <NUM> may utilize a portion of secondary memory <NUM> for storage of data. For example, cryptographic domain <NUM>-<NUM> may utilize cryptographic domain storage <NUM>-<NUM>, cryptographic domain <NUM>-<NUM> may be associated with cryptographic domain storage <NUM>-<NUM>, and cryptographic domain <NUM>-n may be associated with cryptographic domain storage <NUM>-n. As shown in <FIG>, memory pages <NUM>-<NUM>, <NUM>-<NUM> of main memory <NUM> are allocated to cryptographic domain <NUM>-<NUM>, memory page <NUM>-n of main memory <NUM> is allocated to cryptographic domain <NUM>-n, and no memory pages are allocated to cryptographic domain <NUM>-<NUM>.

In various embodiments, portions of the data stored in a respective cryptographic domain storage of secondary memory <NUM> may be loaded into memory pages of main memory <NUM> that are allocated to the cryptographic domain that corresponds to the respective cryptographic domain storage. In various such embodiments, the portions of data may be loaded into memory pages for execution, analysis, and/or manipulation by a processing core (e.g., one or more of processing cores <NUM>). For example, data for cryptographic domain <NUM>-<NUM> may be loaded into memory page <NUM>-<NUM> and/or memory page <NUM>-<NUM> from cryptographic domain storage <NUM>-<NUM>.

In various embodiments described herein, the number of memory pages allocated to a cryptographic domain may be based on the amount of data that needs to be readily accessible to processing cores to perform a requested function, such as running a program on an instantiated VM. In some embodiments, data in secondary memory <NUM> may be encrypted/decrypted with a corresponding domain key as the data is moved to/from the secondary memory. In one or more embodiments, associations between memory and cryptographic domains may be tracked via one or more memory mappings. In one or more such embodiments, the one or more memory mappings may be replaced or revised as part of allocating/reallocating memory to different cryptographic domains.

In many embodiments, data in main memory <NUM> may be cached in one or more of the core caches <NUM> and the shared cache <NUM> as it is utilized by a processing core according to a cache algorithm. In one or more embodiments, caching may be used to improve memory performance by keeping frequently used data in memory with a lower access latency. As shown in <FIG>, each of the cache lines in the caches may be associated with the memory page from which its contents came from. In various embodiments, a key identifier associated with the cryptographic domain to which the memory page is allocated may associate a cache line with a memory page. In some embodiments, the key identifier may form a portion of a memory address of the cache line and/or the memory page.

Referring to <FIG>, in operating environment <NUM>, cryptographic domain <NUM>-<NUM> may become active and VM <NUM>-<NUM> may be instantiated therein. In many embodiments, to instantiate VM <NUM>-<NUM> in cryptographic domain <NUM>-<NUM>, data from cryptographic domain storage <NUM>-<NUM> may need to be loaded into main memory <NUM>. In some embodiments, memory errors caused by memory integrity failures may be indicated by setting a poison bit on erroneous cache lines to indicate there was an error with the associated memory load. As shown in <FIG>, to support instantiation of VM <NUM>-<NUM>, memory page <NUM>-<NUM> may be reallocated from cryptographic domain <NUM>-<NUM> to cryptographic domain <NUM>-<NUM>. In other embodiments, memory page reallocation from a first cryptographic domain to a second cryptographic domain may occur in response to VM teardown in the first cryptographic domain. Reallocation of a memory page from a first cryptographic domain to a second cryptographic domain will be described in more detail below, such as with respect to <FIG> and <FIG>. In various embodiments, reallocating memory page <NUM>-<NUM> from cryptographic domain <NUM>-<NUM> to cryptographic domain <NUM>-<NUM> may include updating a memory mapping.

Referring to <FIG>, all cache lines in core caches <NUM> and shared cache <NUM> that are associated with the reallocated memory page <NUM>-<NUM> need to be flushed and/or invalidated to ensure function correctness, such as memory errors. For instance, if data stored in core cache line <NUM>-n associated with cryptographic domain <NUM>-<NUM> remained after reallocation of memory page <NUM>-<NUM> from cryptographic domain <NUM>-<NUM> to cryptographic domain <NUM>-<NUM>, then the data may cause memory errors when evicted from the cache because of its association with cryptographic domain <NUM>-<NUM>. Accordingly, cache line <NUM>-n of core cache <NUM>-<NUM>, cache line <NUM>-<NUM> of core cache <NUM>-<NUM>, and shared cache line <NUM>-n of shared cache <NUM> may need to be invalidated and/or disassociated with memory page <NUM>-<NUM>. This process will be described in more detail below, such as with respect to <FIG>.

<FIG> illustrates one embodiment of a logic flow <NUM>, which may be representative of operations that may be executed and/or implemented in various embodiments in conjunction with dynamically allocating resource among cryptographic domains. The logic flow <NUM> may be representative of some or all of the operations that may be executed and/or implemented by one or more components of operating environments <NUM>, <NUM>, <NUM>, such as by RMGR <NUM> or processing cores <NUM> (e.g., in executing PGINVDREMAP).

In the illustrated embodiment shown in <FIG>, the logic flow <NUM> may begin at block <NUM>. At block <NUM> "make page inaccessible to a first VM" the memory page being reassigned may be made inaccessible to a first VM that the memory page is being reassigned from. For example, if memory page <NUM>-n is being reassigned from VM <NUM>-<NUM> to VM <NUM>-<NUM>, then memory page <NUM>-n may be made inaccessible to components of cryptographic domain <NUM>-<NUM>. In some embodiments, making a memory page inaccessible to the first VM may include invalidating or updating one or more of memory mappings <NUM>. In some embodiments, invalidating memory mappings may include one or more of invalidating mappings from a translation lookaside buffer, input/output memory management unit (IOMMU) invalidation (e.g., if the page was device accessible), and marking the page as not present in page table structures, such as extended page tables managed by the VMM.

Proceeding to block <NUM> "read and store the page to a portion of secondary memory associated with the first VM" the memory page may be read and stored to a portion of secondary memory that is associated with the first VM. For example, if cryptographic domain storage <NUM>-<NUM> is associated with the cryptographic domain of the first VM, then the contents of the memory page may be read and stored to cryptographic domain storage <NUM>-<NUM>. In various embodiments, the contents of the memory page may be encrypted prior to being stored to cryptographic domain storage <NUM>-<NUM>. For instance, the domain key of domain keys <NUM> that is associated with the cryptographic domain of the first VM may be used to encrypt the contents of the memory page before the contents are stored to cryptographic domain storage <NUM>-<NUM>. In some embodiments, block <NUM> may be repeated until all the contents of the memory page have been stored to cryptographic domain storage <NUM>-<NUM>.

At block <NUM> "PGINVDREMAP" a new instruction referred to as PGINVDREMAP may be executed. In various embodiments described herein, PGINVDREMAP may be a new instruction that combines invalidation of cache lines and integrity value reinitialization operations. In many embodiments, PGINVDREMAP may ensure that the memory page is invalidated from the cache hierarchy using a first key or first key identifier that is associated with the cryptographic domain the memory page is being reassigned from. Additionally, or alternatively, PGINVDREMAP may ensure that integrity values, such as message authentication codes (MACs) are generated using a second key or second key identifier that is associated with the cryptographic domain the memory page is being reassigned to. In one or more embodiments described herein, PGINVDREMAP may operate at the granularity of a memory page. It will be appreciated that in various embodiments an old key or old key identifier may refer to the key or key identifier that is associated with the cryptographic domain the memory page is being reassigned from and a new key or new key identifier may refer to the key or key identifier that is associated with the cryptographic domain the memory page is being reassigned to.

In various embodiments, PGINVDREMAP may be a ring-<NUM> instruction. In many embodiments, PGINVDREMAP may take one or more of the following parameters: (<NUM>) the address of the memory page to be reassigned; (<NUM>) the old key identifier; (<NUM>) the new key identifier; and (<NUM>) whether integrity values associated with the page need initialization. In various such embodiments, the address of the memory page to be reassigned may include the linear address of the memory page to be reassigned. In some embodiments, as mentioned above, the initialization of integrity values may be controlled based on an input to the PGINVDREMAP instruction. In some such embodiments, this may enable efficient key re-assignment for a page whether or not memory integrity is utilized. In many embodiments, using these parameters, PGINVDREMAP may issue a command to all cores (e.g., processing cores <NUM>) to invalidate the memory page from their caches (e.g., core caches <NUM> and shared cache <NUM>). In one or more embodiments, the old key identifier passed as a parameter may be used for invalidation operations. In various embodiments, the new key identifier may then be used by PGINVDREMAP to zero out the memory page. In some embodiments, such as when integrity is enabled, the integrity values (e.g., MACs) for the memory page may be reinitialized with the new key identifier.

In many embodiments, PGINVDREMAP may operate across a single socket. In many such embodiments, if the platform has multiple sockets, software may be included, such as in RMGR <NUM>, to execute the instruction for each socket to achieve desired functionality. In one or more embodiments, software may be included, such as in RMGR <NUM> to specify the old and new key identifier for the physical page being reassigned. In various embodiments, existing caching components, such as a snoop filter, may be utilized to support page invalidation.

In several embodiments, execution of PGINVDREMAP on a logical processor may result in the broadcast of a single invalidate message to all other cores on the platform in the same socket. For instance, the instruction may send a new message, referred to as invd_page, to each of the cores in the socket over an interconnect (e.g. mesh). In many embodiments, the invd_page message may include the old key identifier and the physical address of the memory page to invalidate. In various embodiments, each core (e.g., processing cores <NUM>), upon receiving the invd_page message may check its local caches for any of the lines belonging to the memory page being reassigned.

In many embodiments, the invd_page message may utilize caching hardware that supports snooping and invalidation of cache lines, such as for coherence. In many such embodiments, the invd_page message utilizes the caching hardware to locate cache lines associated with the memory page. In some embodiments, the lookup for the page cache lines may be done with the old key identifier to find the lines of the memory page when it was used with the VM associated with the old key identifier (i.e. the first VM). The flow for page invalidation with the old key identifier will be described in more detail below, such as with respect to <FIG>.

In some embodiments, such as when integrity is enabled, the integrity values (e.g., MACs) for the memory page may be reinitialized with the new key identifier once invalidation of the cache lines is complete. In many embodiments described herein, PGINVDREMAP may utilize architecturally guaranteed non-temporal writes for reinitializing integrity values to enable integrity to be supported for VM isolation. In various embodiments, without non-temporal writes, the integrity value associated with a cache line in memory may still correspond to the old key, and a read from the new page with the new key could cause an integrity failure. Accordingly, a non-temporal write may be performed for each of the lines in the page using the new key. In several embodiments, a non-temporal write may comprise a write in which a cache line is written to without reading it from memory. In many embodiments, PGINVDREMAP may not wait for the non-temporal write operations to finish. In many such embodiments, logic may use fencing operations to ensure completion of memory access done by the PGINVDREMAP instruction and/or correct operation.

Referring back to the logic flow <NUM>, once block <NUM> has completed the logic flow may proceed to block <NUM>. At block <NUM> "map the page to an address space of the second VM" the memory page may be mapped to an address space of the second VM. For instance, the address space of the second VM may include at least a portion of an address space for the cryptographic domain associated with the second VM. In some embodiments, this may include updating, revising, and/or replacing one or more of memory mappings <NUM>.

<FIG> illustrates one embodiment of a logic flow <NUM>, which may be representative of operations that may be executed and/or implemented in various embodiments in conjunction with page invalidation during a reallocation of resources from a first cryptographic domain to a second cryptographic domain. Generally, the logic flow <NUM> may iterate over each line in a page and consult snoop filter hardware to determine whether the line is cached or not, such as in a core cache or a shared cached. The logic flow <NUM> may be representative of some or all of the operations that may be executed and/or implemented by one or more components of operating environments <NUM>, <NUM>, <NUM>, such as by RMGR <NUM> or processing cores <NUM> (e.g., in executing PGINVDREMAP).

In the illustrated embodiment shown in <FIG>, the logic flow <NUM> may begin at block <NUM>. At block <NUM> "ADDR ← PAGE_BASE_ADDR" the page base address is set as the evaluation address. For instance, the page base address may be the physical address of a memory page to invalidate. Continuing to block <NUM> "ADDR in snoop filter?" it may be determined whether the evaluation address is in the snoop filter. For example, processing core <NUM>-<NUM> may consult snoop filter hardware to determine whether the physical address of memory page <NUM>-<NUM> is in core cache <NUM>-<NUM> and/or at least a portion of shared cache <NUM>. In various embodiments, processing cores <NUM>-<NUM>, <NUM>-n may perform similar procedures. In various such embodiments, one or more of the processing cores <NUM> may perform these procedures in parallel. In many embodiments, snoop filter hardware may maintain information regarding the lines that are cached in a particular core's cache.

If the evaluation address is found in the snoop filter, the logic flow <NUM> may proceed to block <NUM>. At block <NUM> "invalidate ADDR in core cache hierarchy" the evaluation address may be invalidated in a core cache hierarchy. For instance, if processing core <NUM>-<NUM> locates the evaluation address in snoop filter hardware, then the processing core <NUM>-<NUM> may invalidate the corresponding cache line in the cache hierarchy comprising core cache <NUM>-<NUM> and shared cache <NUM>. In various embodiments, in addition to issuing the invd_page message in response to identifying an evaluation address in the snoop filter, the page may also be invalidated from a last level cache (LLC). For example, shared cache <NUM> may be an LLC. In many embodiments, the evaluation address may be invalidated in the LLC by sending invalidation messages for each cache line in the page to the LLC slices where the cache line maps to. In such embodiments, there may be a unique LLC slice to which each cache line can map to using a fixed hashing function in the core). In some embodiments, there may be two or more levels in the cache hierarchy. Next, the logic flow <NUM> may proceed to block <NUM> as will be described in more detail below.

Referring back to block <NUM>, if the evaluation address is not found in the snoop filter, the logic flow <NUM> may proceed to block <NUM>. At block <NUM> "ADDR last cache line in the page?" it may be determined whether the evaluation address was the last cache line in the page. If the evaluation address is not the last cache line in the page then the logic flow <NUM> may proceed to block <NUM>. At block <NUM> "ADDR = ADDR + 64B" the evaluation address may be updated to the next cache line. In the illustrated embodiments, each memory line may be 64B, thus adding 64B to the previous evaluation address can set a new evaluation address corresponding to a subsequent line in the memory page. Next, the logic flow <NUM> may return to block <NUM>.

Referring back to block <NUM>, if the evaluation address is the last cache line in the page, then the logic flow <NUM> may proceed to block <NUM>. At block <NUM> "send ACK back to requesting core" an acknowledgement message may be sent back to the core requesting the invalidation. In various embodiments, the acknowledgement message may be in response to the invd_page message. For instance, the acknowledgement message may be in response to execution of PGINVDREMAP may a logical processor that results in broadcast of the invd_page message to all other cores in the platform <NUM> that are on the same socket. In many embodiments, once the requesting core receives acknowledgement messages from all other cores in the socket on invalidation completion, it may be guaranteed that the page with the old key identifier is not cached in the socket on any of the cores.

<FIG> illustrates one embodiment of a logic flow <NUM>, which may be representative of operations that may be executed and/or implemented in various embodiments in conjunctions with resource allocation management. The logic flow <NUM> may be representative of some or all of the operations that may be executed and/or implemented by one or more components of operating environments <NUM>, <NUM>, <NUM> of <FIG>, such as by RMGR <NUM> or processing cores <NUM> (e.g., in executing PGINVDREMAP).

In the illustrated embodiment shown in <FIG>, the logic flow <NUM> may begin at block <NUM>. At block <NUM> "identify a first key identifier associated with a first virtual machine (VM), a second key identifier associated with a second VM, and an address of a memory page allocated to the first VM" a first key identifier associated with a first VM, a second key identifier associated with a second VM, and an address of a memory page allocated to the first VM may be identified. For example, a key identifier associated with VM <NUM>-<NUM>, a key identifier associated with VM <NUM>-<NUM>, and an address of memory page <NUM>-<NUM> may be identified. At block <NUM> "invalidate a cache line associated with the first VM based on the first key identifier" a cache line associated with the first VM may be invalidated based on the first key identifier. For instance, one or more of core cache lines <NUM>-n, <NUM>-<NUM>, <NUM>-n may be invalidated based on their associated with the first key identifier.

Continuing to block <NUM> "generate a message authentication code (MAC) for each cache line comprising the memory page based on the second key identifier" a MAC for each cache line in the memory page may be generated based on the second key identifier. For example, a MAC for memory page <NUM>-<NUM> (i.e., each cache line comprising the memory page <NUM>-<NUM>) may be generated based on the key identifier associated with VM <NUM>-<NUM>. At block <NUM> "allocate the memory page to the second VM" the memory page may be allocated to the second VM. For instance, the memory page <NUM>-<NUM> may be allocated to VM <NUM>-<NUM>.

<FIG> illustrates an embodiment of a storage medium <NUM>. Storage medium <NUM> may comprise any non-transitory computer-readable storage medium or machine-readable storage medium, such as an optical, magnetic or semiconductor storage medium. In various embodiments, storage medium <NUM> may comprise an article of manufacture. In some embodiments, storage medium <NUM> may store computer-executable instructions, such as computer-executable instructions to implement one or more of logic flows or operations described herein, such as with respect to logic flows <NUM>, <NUM>, and <NUM> of <FIG>, <FIG>, and <FIG>. Examples of a computer-readable storage medium or machine-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of computer-executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like.

<FIG> illustrates an embodiment of an exemplary computing architecture <NUM> that may be suitable for implementing various embodiments as previously described. In various embodiments, the computing architecture <NUM> may comprise or be implemented as part of an electronic device. In some embodiments, the computing architecture <NUM> may be representative, for example, of a computer system that implements one or more components of operating environments <NUM>, <NUM>, <NUM> of <FIG>. In some embodiments, computing architecture <NUM> may be representative, for example, one or more portions of RMGR <NUM> and/or processing cores <NUM> that implement one or more embodiments described herein.

As used in this application, the terms "system" and "component" and "module" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture <NUM>. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the uni-directional or bidirectional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

As shown in <FIG>, the computing architecture <NUM> comprises a processing unit <NUM>, a system memory <NUM> and a system bus <NUM>. The processing unit <NUM> can be any of various commercially available processors, including without limitation an AMD® Athlon®, Duron® and Opteron® processors; ARM® application, embedded and secure processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; Intel® Celeron®, Core (<NUM>) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be employed as the processing unit <NUM>.

The system memory <NUM> may include various types of computer-readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RMGR), dynamic RMGR (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RMGR (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., one or more flash arrays), polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information.

The computer <NUM> may include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal (or external) hard disk drive (HDD) <NUM>, a magnetic floppy disk drive (FDD) <NUM> to read from or write to a removable magnetic disk <NUM>, and an optical disk drive <NUM> to read from or write to a removable optical disk <NUM> (e.g., a CD-ROM or DVD). The HDD <NUM>, FDD <NUM> and optical disk drive <NUM> can be connected to the system bus <NUM> by a HDD interface <NUM>, an FDD interface <NUM> and an optical drive interface <NUM>, respectively. The HDD interface <NUM> for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE <NUM> interface technologies.

The drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For example, a number of program modules can be stored in the drives and memory units <NUM>, <NUM>, including an operating system <NUM>, one or more application programs <NUM>, other program modules <NUM>, and program data <NUM>. In one embodiment, the one or more application programs <NUM>, other program modules <NUM>, and program data <NUM> can include, for example, the various applications and/or components of the RMGR <NUM> and/or other logic described herein.

A user can enter commands and information into the computer <NUM> through one or more wire/wireless input devices, for example, a keyboard <NUM> and a pointing device, such as a mouse <NUM>. Other input devices may include microphones, infra-red (IR) remote controls, radio-frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like. These and other input devices are often connected to the processing unit <NUM> through an input device interface <NUM> that is coupled to the system bus <NUM>, but can be connected by other interfaces such as a parallel port, IEEE <NUM> serial port, a game port, a USB port, an IR interface, and so forth.

In various embodiments, one or more migrations may occur via the networked environment.

When used in a WAN networking environment, the computer <NUM> can include a modem <NUM>, or is connected to a communications server on the WAN <NUM>, or has other means for establishing communications over the WAN <NUM>, such as by way of the Internet. The modem <NUM>, which can be internal or external and a wire and/or wireless device, connects to the system bus <NUM> via the input device interface <NUM>. In a networked environment, program modules depicted relative to the computer <NUM>, or portions thereof, can be stored in the remote memory/storage device <NUM>. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

The computer <NUM> is operable to communicate with wire and wireless devices or entities using the IEEE <NUM> family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE <NUM> over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, among others. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE <NUM>. 11x (a, b, g, n, etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wire networks (which use IEEE <NUM>-related media and functions).

<FIG> illustrates a block diagram of an exemplary communications architecture <NUM> suitable for implementing various embodiments as previously described, such as virtual machine migration. The communications architecture <NUM> includes various common communications elements, such as a transmitter, receiver, transceiver, radio, network interface, baseband processor, antenna, amplifiers, filters, power supplies, and so forth. The embodiments, however, are not limited to implementation by the communications architecture <NUM>.

As shown in <FIG>, the communications architecture <NUM> comprises includes one or more clients <NUM> and servers <NUM>. The clients <NUM> and the servers <NUM> are operatively connected to one or more respective client data stores <NUM> and server data stores <NUM> that can be employed to store information local to the respective clients <NUM> and servers <NUM>, such as cookies and/or associated contextual information. In various embodiments, any one of servers <NUM> may implement one or more of logic flows or operations described herein, and storage medium <NUM> of <FIG> in conjunction with storage of data received from any one of clients <NUM> on any of server data stores <NUM>.

The clients <NUM> and the servers <NUM> may communicate information between each other using a communication framework <NUM>. The communications framework <NUM> may implement any well-known communications techniques and protocols. The communications framework <NUM> may be implemented as a packet-switched network (e.g., public networks such as the Internet, private networks such as an enterprise intranet, and so forth), a circuit-switched network (e.g., the public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (with suitable gateways and translators).

The communications framework <NUM> may implement various network interfaces arranged to accept, communicate, and connect to a communications network. A network interface may be regarded as a specialized form of an input output interface. Network interfaces may employ connection protocols including without limitation direct connect, Ethernet (e.g., thick, thin, twisted pair <NUM>/<NUM>/<NUM> Base T, and the like), token ring, wireless network interfaces, cellular network interfaces, IEEE <NUM>. 11a-x network interfaces, IEEE <NUM> network interfaces, IEEE <NUM> network interfaces, and the like. Further, multiple network interfaces may be used to engage with various communications network types. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and unicast networks. Should processing requirements dictate a greater amount speed and capacity, distributed network controller architectures may similarly be employed to pool, load balance, and otherwise increase the communicative bandwidth required by clients <NUM> and the servers <NUM>. A communications network may be any one and the combination of wired and/or wireless networks including without limitation a direct interconnection, a secured custom connection, a private network (e.g., an enterprise intranet), a public network (e.g., the Internet), a Personal Area Network (PAN), a Local Area Network (LAN), a Metropolitan Area Network (MAN), an Operating Missions as Nodes on the Internet (OMNI), a Wide Area Network (WAN), a wireless network, a cellular network, and other communications networks.

Some embodiments may be implemented, for example, using a machine-readable medium or article which may store an instruction or a set of instructions that, if executed by a machine, may cause the machine to perform a method and/or operations in accordance with the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and/or software. The machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and/or storage unit, for example, memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disk (DVD), a tape, a cassette, or the like. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.

The following examples pertain to further embodiments, from which numerous permutations and configurations will be apparent.

Example <NUM> is an apparatus for resource allocation management, the apparatus comprising: logic, at least a portion of the logic implemented in circuitry, the logic to: identify a first key identifier associated with a first virtual machine (VM), a second key identifier associated with a second VM, and an address of a memory page allocated to the first VM; invalidate a cache line associated with the first VM based on the first key identifier; generate a message authentication code (MAC) for each cache line comprising the memory page based on the second key identifier; and allocate the memory page to the second VM.

Example <NUM> includes the subject matter of Example <NUM>, the logic to: invalidate a first mapping of the memory page to the first VM; and generate a second mapping of the memory page to the second VM.

Example <NUM> includes the subject matter of Example <NUM>, the logic to initialize the MAC for each cache line comprising the memory page with a non-temporal write.

Example <NUM> includes the subject matter of Example <NUM>, the logic to utilize a fencing operation to ensure correct operation of the non-temporal write.

Example <NUM> includes the subject matter of Example <NUM>, the non-temporal write to include a write to the cache line without reading the cache line from the memory page.

Example <NUM> includes the subject matter of Example <NUM>, the non-temporal write architecturally guaranteed.

Example <NUM> includes the subject matter of Example <NUM>, the logic to identify the cache line to invalidate based on the first key identifier and a snoop filter.

Example <NUM> includes the subject matter of Example <NUM>, the logic to invalidate the cache line associated with the first VM and generate the MAC for each cache line comprising the memory page in response to execution of a ring-<NUM> instruction or an instruction included in an instruction set architecture (ISA).

Example <NUM> includes the subject matter of Example <NUM>, the logic to generate a message for a set of processing cores comprising the first key identifier and the address of the memory page, the message to cause the set of processing cores to invalidate cache lines associated with the first VM.

Example <NUM> includes the subject matter of Example <NUM>, the logic to identify an acknowledgement from each processing core in the set of processing cores, the acknowledgement to indicate cache lines associated with the first VM have been invalidated.

Example <NUM> includes the subject matter of Example <NUM>, the logic to invalidate a second cache line in a shared cache based on the cache line associated with the first VM mapping to the second cache line in the shared cache.

Example <NUM> includes the subject matter of Example <NUM>, the shared cache comprising a last level cache (LLC).

Example <NUM> includes the subject matter of Example <NUM>, the address of the memory page allocated to the first VM comprising a linear address of the memory page.

Example <NUM> includes the subject matter of Example <NUM>, the cache line associated with the first VM comprised in a core cache.

Example <NUM> includes the subject matter of Example <NUM>, the memory page comprised in random access memory.

Example <NUM> includes the subject matter of Example <NUM>, the logic to: identify a key associated with the first VM based on the first key identifier; and generate the MAC for each cache line comprising the memory page with the key.

Example <NUM> is a method for resource allocation management, the method comprising: identifying a first key identifier associated with a first virtual machine (VM), a second key identifier associated with a second VM, and an address of a memory page allocated to the first VM; invalidating a cache line associated with the first VM based on the first key identifier; generating a message authentication code (MAC) for each cache line comprising the memory page based on the second key identifier; and allocating the memory page to the second VM.

Example <NUM> includes the subject matter of Example <NUM>, comprising: invalidating a first mapping of the memory page to the first VM; and generating a second mapping of the memory page to the second VM.

Example <NUM> includes the subject matter of Example <NUM>, comprising initializing the MAC for each cache line comprising the memory page with a non-temporal write.

Example <NUM> includes the subject matter of Example <NUM>, comprising utilizing a fencing operation to ensure correct operation of the non-temporal write.

Example <NUM> includes the subject matter of Example <NUM>, the non-temporal write comprising a write to the cache line without reading the cache line from the memory page.

Example <NUM> includes the subject matter of Example <NUM>, comprising identifying the cache line to invalidate based on the first key identifier and a snoop filter.

Example <NUM> includes the subject matter of Example <NUM>, comprising invalidating the cache line associated with the first VM and generate the MAC for each cache line comprising the memory page in response to execution of a ring-<NUM> instruction or an instruction included in an instruction set architecture (ISA).

Example <NUM> includes the subject matter of Example <NUM>, comprising generating a message for a set of processing cores comprising the first key identifier and the address of the memory page, the message to cause the set of processing cores to invalidate cache lines associated with the first VM.

Example <NUM> includes the subject matter of Example <NUM>, comprising identifying an acknowledgement from each processing core in the set of processing cores, the acknowledgement to indicate cache lines associated with the first VM have been invalidated.

Example <NUM> includes the subject matter of Example <NUM>, comprising invalidating a second cache line in a shared cache based on the cache line associated with the first VM mapping to the second cache line in the shared cache.

Example <NUM> includes the subject matter of Example <NUM>, comprising: identifying a key associated with the first VM based on the first key identifier; and generating the MAC for each cache line comprising the memory page with the key.

Example <NUM> is at least one non-transitory computer-readable medium comprising a set of instructions that, in response to being executed by a processor circuit, cause the processor circuit to: identify a first key identifier associated with a first virtual machine (VM), a second key identifier associated with a second VM, and an address of a memory page allocated to the first VM; invalidate a cache line associated with the first VM based on the first key identifier; generate a message authentication code (MAC) for each cache line comprising the memory page based on the second key identifier; and allocate the memory page to the second VM.

Example <NUM> includes the subject matter of Example <NUM>, comprising instructions that, in response to being executed by the processor circuit, cause the processor circuit to: invalidate a first mapping of the memory page to the first VM; and generate a second mapping of the memory page to the second VM.

Example <NUM> includes the subject matter of Example <NUM>, comprising instructions that, in response to being executed by the processor circuit, cause the processor circuit to initialize the MAC for each cache line comprising the memory page with a non-temporal write.

Example <NUM> includes the subject matter of Example <NUM>, comprising instructions that, in response to being executed by the processor circuit, cause the processor circuit to utilize a fencing operation to ensure correct operation of the non-temporal write.

Example <NUM> includes the subject matter of Example <NUM>, comprising instructions that, in response to being executed by the processor circuit, cause the processor circuit to identify the cache line to invalidate based on the first key identifier and a snoop filter.

Example <NUM> includes the subject matter of Example <NUM>, comprising instructions that, in response to being executed by the processor circuit, cause the processor circuit to invalidate the cache line associated with the first VM and generate the MAC for each cache line comprising the memory page in response to execution of a ring-<NUM> instruction or an instruction included in an instruction set architecture (ISA).

Example <NUM> includes the subject matter of Example <NUM>, comprising instructions that, in response to being executed by the processor circuit, cause the processor circuit to generate a message for a set of processing cores comprising the first key identifier and the address of the memory page, the message to cause the set of processing cores to invalidate cache lines associated with the first VM.

Example <NUM> includes the subject matter of Example <NUM>, comprising instructions that, in response to being executed by the processor circuit, cause the processor circuit to identify an acknowledgement from each processing core in the set of processing cores, the acknowledgement to indicate cache lines associated with the first VM have been invalidated.

Example <NUM> includes the subject matter of Example <NUM>, comprising instructions that, in response to being executed by the processor circuit, cause the processor circuit to invalidate a second cache line in a shared cache based on the cache line associated with the first VM mapping to the second cache line in the shared cache.

Example <NUM> includes the subject matter of Example <NUM>, comprising instructions that, in response to being executed by the processor circuit, cause the processor circuit to: identify a key associated with the first VM based on the first key identifier; and generate the MAC for each cache line comprising the memory page with the key.

Example <NUM> is an apparatus for resource allocation management, the apparatus comprising: means for identifying a first key identifier associated with a first virtual machine (VM), a second key identifier associated with a second VM, and an address of a memory page allocated to the first VM; means for invalidating a cache line associated with the first VM based on the first key identifier; means for generating a message authentication code (MAC) for each cache line comprising the memory page based on the second key identifier; and means for allocating the memory page to the second VM.

Example <NUM> includes the subject matter of Example <NUM>, comprising: means for invalidating a first mapping of the memory page to the first VM; and means for generating a second mapping of the memory page to the second VM.

Example <NUM> includes the subject matter of Example <NUM>, comprising means for initializing the MAC for each cache line comprising the memory page with a non-temporal write.

Example <NUM> includes the subject matter of Example <NUM>, comprising means for utilizing a fencing operation to ensure correct operation of the non-temporal write.

Example <NUM> includes the subject matter of Example <NUM>, comprising means for identifying the cache line to invalidate based on the first key identifier and a snoop filter.

Example <NUM> includes the subject matter of Example <NUM>, comprising means for invalidating the cache line associated with the first VM and generate the MAC for each cache line comprising the memory page in response to execution of a ring-<NUM> instruction or an instruction included in an instruction set architecture (ISA).

Example <NUM> includes the subject matter of Example <NUM>, comprising means for generating a message for a set of processing cores comprising the first key identifier and the address of the memory page, the message to cause the set of processing cores to invalidate cache lines associated with the first VM.

Example <NUM> includes the subject matter of Example <NUM>, comprising means for identifying an acknowledgement from each processing core in the set of processing cores, the acknowledgement to indicate cache lines associated with the first VM have been invalidated.

Example <NUM> includes the subject matter of Example <NUM>, comprising means for invalidating a second cache line in a shared cache based on the cache line associated with the first VM mapping to the second cache line in the shared cache.

Example <NUM> includes the subject matter of Example <NUM>, comprising: means for identifying a key associated with the first VM based on the first key identifier; and means for generating the MAC for each cache line comprising the memory page with the key.

Claim 1:
A method for resource allocation management, the method comprising:
identifying a first key identifier associated with a first virtual machine, VM, (<NUM>-<NUM>) a second key identifier associated with a second VM (<NUM>-<NUM>), and an address of a memory page (<NUM>-n) allocated to the first VM;
allocating the memory page to the second VM, comprising:
invalidating a first mapping of the memory page to the first VM;
generating a second mapping of the memory page to the second VM;
generating a message authentication code (MAC) for each cache line comprising the memory page based on the second key identifier and initializing the MAC for each cache line of the memory page with a non-temporal write;
the non-temporal write comprising a write to the cache line without reading the cache line from the memory page; wherein
if a processing core (<NUM>-<NUM>) locates an evaluation address in snoop filter hardware, then the processing core (<NUM>-<NUM>) invalidates the corresponding cache line in the cache hierarchy; wherein
the evaluation address is invalidated in a last level cache, LLC, by sending invalidation messages for each cache line in the page to the LLC slices where the cache line maps to.