so the code in tryLockVMOwner is

        mov $1, %eax

        mfence

        xchg %eax, vmOwnerLock

        sfence

        sub $1, %eax    "Since we only ever set the lock to 1 or 0, subtracting 1 sets EAX to 0 if the lock was already locked and non-zero if it wasn't."

        ret

i.e. it attempts to set vmOwnerLock and answers if the attempt succeeded, where it will only succeed if vmOwnerLock was zero.  So I guess the system is never arranging to unlock the Vm so there is never any opportunity for the foreign callback to get entry.  Try adding an occasional "Processor relinquishProcessorForMicroseconds: 100" and see if that gives your call-back a window.  Ideally you'd only do such a thing when the system is  ready to accept callbacks.  I expect the foreign callback logic is wrong in only allowing callbacks when the VM is unlocked.  Instead, the system should probably see if the foreign callback priority is greater than the current process's priority, and then somehow preempt the current process (e.g. by setting stackLimit appropriately).  But I have no cycles to think about this right now.