On Wed, May 14, 2025 at 07:20:18AM +0800, Edgecombe, Rick P wrote: > On Thu, 2025-04-24 at 11:09 +0800, Yan Zhao wrote: > > Introduce a "prefetch" parameter to the private_max_mapping_level hook and > > enforce the max mapping level of a prefetch fault for private memory to be > > 4KB. This is a preparation to enable the ignoring huge page splitting in > > the fault path. > > > > If a prefetch fault results in a 2MB huge leaf in the mirror page table, > > there may not be a vCPU available to accept the corresponding 2MB huge leaf > > in the S-EPT if the TD is not configured to receive #VE for page > > acceptance. > > > > Can you elaborate on this case more. A vCPU may not be available? What does that > mean? Sorry. I didn't express it clearly. If a prefetch fault results in a 2MB mapping, as the guest is not aware of the prefetched mapping, it may accept at 4KB later, triggering a demotion. > > Consequently, if a vCPU accepts the page at 4KB level, it will > > trigger an EPT violation to split the 2MB huge leaf generated by the > > prefetch fault. > > The case is KVM_PRE_FAULT_MEMORY faults in 2MB, then guest accepts at 4k (which > it is not supposed to do)? Actually, the guest is innocent to accept at 4KB. > Then maybe the kvm_vm_dead() case I suggested in the other patch could handle > this case too, and this patch could be dropped? This patch is not required if we decide to support demotion in the fault path. > > Since handling the BUSY error from SEAMCALLs for huge page splitting is > > more comprehensive in the fault path, which is with kvm->mmu_lock held for > > reading, force the max mapping level of a prefetch fault of private memory > > to be 4KB to prevent potential splitting. >
