Indan Zupancic
Indan Zupancic
I recommend keeping counts of each event and printing out the totals now and then. Sharing a UART with multiple cores is unreliable in the sense that output of one...
> I'm just failing to see a state where I'd expect to see this behavior. Agreed. To me `handleVmexit()` seems suspicious, maybe add some printfs there to see if the...
> In handleVmexit, the thread state would still be ThreadState_RunningVM, as that isn't updated til handleVmxFault That is not true: `VMCheckBoundNotification` can have run before that, when `handleVmexit` attempts to...
Incidentally, I intend to change the code so that if an IPI is handled when trying to take the lock, we return to user space instead of continuing, as that...
> Now the question needs to be, how do we address this? Let's try a `restore_user_context()` after both `handleIPI()` calls in lock.h and see if that solves it for you....
Bummer, that's unexpected. Is it broken immediately, or does it break after a while?
Yes, it is, but.. Oops, we can only do the restore after we released the lock. So set an ipi flag and check the flag at the end of `clh_lock_acquire()`,...
No, `sel4_atomic_exchange` needs to set the same flag (or add a return code). And before restoring the user context, call `clh_lock_release()`.
So the below diff is not exactly what I said, but the main thing is that once we request the lock, we are committed and need to finish getting it,...
Worth a try, to see if it works at least. I really want to fix all similar bugs by exiting the kernel after an IPI, but I'll keep working on...