sgx_encl_cpumask(9)

okay so bestie, welcome to the sgx_encl_cpumask(9) page from the Kernel API Manual ✨ this one is all about figuring out which CPUs might be touching an enclave, and honestly it's giving careful-coordination energy 💅

🌸 NAME 🌸

sgx_encl_cpumask — query which CPUs might be accessing the enclave 👀

✨ SYNOPSIS ✨

const cpumask_t * sgx_encl_cpumask (struct sgx_encl *encl );

🎀 ARGUMENTS 🎀

• encl — the enclave 🫶

💖 DESCRIPTION 💖

okay so here's the lore: some SGX functions literally require that no cached linear-to-physical address mappings are present before they can succeed. Example: ENCLS[EWB] copies a page from the enclave page cache to regular main memory, but it fails if it can't ensure there are no cached linear-to-physical address mappings referring to that page 😭

SGX hardware flushes all cached linear-to-physical mappings on a CPU when an enclave is exited via ENCLU[EEXIT] or an Asynchronous Enclave Exit (AEX). So exiting an enclave will ensure those cached linear-to-physical address mappings are cleared, but coordination with the tracking done within the SGX hardware is needed to support the SGX functions that depend on this cache clearing 🧚

When ENCLS[ETRACK] is issued on an enclave, the hardware tracks threads operating inside the enclave at that time. The SGX hardware tracking requires that all the identified threads must have exited the enclave in order to flush the mappings before a function such as ENCLS[EWB] will be permitted 🔥

The following flow is used to support SGX functions that require that no cached linear-to-physical address mappings are present:

1. Execute ENCLS[ETRACK] to initiate hardware tracking.
2. Use this function (sgx_encl_cpumask) to query which CPUs might be accessing the enclave.
3. Send IPI to identified CPUs, kicking them out of the enclave and thus flushing all locally cached linear-to-physical address mappings.
4. Execute SGX function.

🚨 required tea: all IPIs must be completed before a new ENCLS[ETRACK] is issued, so be sure to protect steps 1 to 3 of the above flow with the enclave's mutex. No skipping this, bestie 💀

🌈 CONTEXT 🌈

It is required to call this function after ENCLS[ETRACK] 👑. This will ensure that if any new mm appears (racing with sgx_encl_mm_add) then the new mm will enter into the enclave with fresh linear-to-physical address mappings ✨

🦋 RETURN 🦋

cpumask of CPUs that might be accessing encl 💅

🌟 SEE ALSO 🌟

• Kernel file ./arch/x86/kernel/cpu/sgx/encl.c
• reclaimer_writing_to_pcmd(9)
• sgx_encl_eaug_page(9)
• sgx_encl_may_map(9)
• sgx_encl_release(9)
• __sgx_encl_get_backing(9)
• sgx_encl_alloc_backing(9)
• sgx_encl_lookup_backing(9)
• sgx_encl_put_backing(9)
• sgx_encl_test_and_clear_young(9)
• sgx_zap_enclave_ptes(9)
• sgx_alloc_va_page(9)
• sgx_alloc_va_slot(9)
• sgx_free_va_slot(9)
• sgx_va_page_full(9)
• sgx_encl_free_epc_page(9)

okay bye bestie 🫶 this page's source/version is ./arch/x86/kernel/cpu/sgx, the date is October 2026, and yes, it's still the sgx_encl_cpumask(9) entry 💖