Restrictions on TLB Flushes

When a virtual processor generates an intercept--especially those intercepts that are associated with memory accesses, software that runs within the parent might need to complete the intercepted instruction in software. This instruction completion logic will need to emulate the address translation that is typically performed by the processor's MMU. If a TLB flush request is executed on another virtual processor during instruction completion, incorrect behavior can result. For example, the second virtual processor could clear the dirty bit within the guest's page table and then request a TLB flush. If the instruction completion software modifies the contents of this page after the TLB flush request has been completed, the operating system that runs within the partition will not be notified of the page modification, and data corruption can occur.

To prevent this situation, the hypervisor provides a way to inhibit TLB flush hypercalls until intercept processing is complete. When a memory intercept message is generated by the hypervisor, the TlbFlushInhibit bit will consequently be set. Any attempt to flush the TLB with a hypercall will place the caller's virtual processor in a suspended state. The instruction pointer will not be incremented past the instruction that made the hypercall. After the memory intercept routine performs instruction completion, the routine should clear the TlbFlushInhibit bit of the HvRegisterInterceptSuspend register. This operation resumes virtual processors that were suspended when they attempted to flush the TLB while the TlbFlushInhibit bit was set. Since the instruction pointer has not been incremented, the flush hypercall will automatically be re-executed. If the TlbFlushInhibit bit is clear, the hypercall will complete the flush normally.

Send comments about this topic to Microsoft

Build date: 11/16/2013