Re: [PATCH] x86/sgx: Periodically yield in EPC sanitization to unblock rcu_tasks GP

["Huang, Kai" <kai.huang@intel.com>]

On Thu, 2026-06-18 at 18:04 +0800, Jun Miao wrote:
> During early boot, ksgxd (Intel Software Guard Extensions Kernel Thread)
> iterates over all post-kexec dirty EPC pages in a tight loop calling
> cond_resched() after each page.  But, on isolated CPUs
> (a common configuration in cloud VMs), cond_resched() never triggers a
> real context switch because TIF_NEED_RESCHED is not set when no competing
> runnable task exists on that CPU.
> 
> synchronize_rcu_tasks(), invoked by BPF LSM during initialization, must
> wait for every task that was running at the start of the grace period to
> pass through a quiescent state (a voluntary sleep or preemption point).
> If ksgxd never leaves the CPU, the rcu_tasks grace period stalls, causing
> boot delays exceeding 60 seconds on machines with large EPC regions.
> 
> Fix this by introducing SGX_SANITIZE_RESCHED_INTERVAL (32768) and forcing
> ksgxd to sleep for one jiffy every that many pages, guaranteeing that an
> rcu_tasks quiescent state is reached in bounded time regardless of CPU
> isolation.  Keep cond_resched() for all other iterations.
> 
> Without this patch, instead, virtual machines (VMs) experience a long OS boot times:

This seems a common problem at the scheduler and RCU layer, but not specific to
SGX.  I originally thought cond_resched() should be able to handle this, but
after reading some history it is not the case.

IIUC, cond_resched_tasks_rcu_qs() was specifically introduced to to address this
issue.  See bde6c3aa9930 ("rcu: Provide cond_resched_rcu_qs() to force quiescent
states in long loops").

Could you try this solution?