Quote:

megol wrote: Let's see... The Page fault handler sends IPI (Inter-Processor Interrupts) to all cores in the system, each IPI handler atomically increases a counter and then goes into a spinloop. The Page fault handler waits until every core have started spinning and then returns to the program making the memory access. Add a permit() path that unlocks all spinning cores and it could perhaps work.

It's missing many details, including turning off preemptive multitasking for the process calling Forbid(), but the main idea is right. It may be better to put the other cores in a low power stopped mode that listens for interrupts (many processors have instructions for this like the 68060 LPSTOP instruction) than the spinlocks if the Permit() IPIs can wake them up. It may be good to preemptively interrupt the Forbid() if it lasts too long, wake up the other core processes and suspend the miss-behaving process.

Quote:

But what about handling disabling/enabling of interrupts? Sure, one could run all code in user mode and trap attempts to manipulate the bit doing something similar as the above...

That is tricky as communicating with the other cores requires interrupts. To be completely safe, the IPI interrupts would have to be the highest priority available. Everything else would be similar to Forbid() except all but the highest level interrupt for the IPI would be disabled on the other cores and all interrupts could be disabled on the current core.

Quote:

I think there will be huge overheads. May be acceptable, haven't programmed modern ARM cores so don't know.

Yes, I agree the overhead would be large if it is even possible. A custom CPU could make it fast, easy and safe. The original Forbid()/Permit() and Disable()/Enable() were huge performance savers as they didn't even require the costly trip to supervisor land.

Let's look at how much difference in responsiveness porting the AmigaOS to other hardware and adding modern feature might make for lower performance hardware (old study with PII@400MHz but it doesn't matter).

https://www.lisha.ufsc.br/wso/wso2009/papers/st04_03.pdf

OS | Response time | Latency | Latency Jitter
Windows XP 200 848 700
uC/OS-II 1.92 3.2 2.32

Windows XP takes 104 times as long to respond, has 265 times the latency and has 301 times as much latency jitter as a RTOS without using the MMU on the same hardware. This is why the AmigaOS was used for the Toaster and even the Toaster for other systems included an Amiga with Toaster. The AmigaOS is probably more marketable in its current form as a RTOS where fast response and low resources are more important than modern security features. Of course that leaves out current AmigaOS users who have learned to love the responsiveness but want more security using current hardware made for virtual address spaces and monolithic kernels. Is it possible for the AmigaOS to add much improved security, add SMP, add 64 bit support, keep 68k compatibility, have responsiveness closer to a RTOS without MMU and maintain a small footprint similar to the original 68k? Not without custom hardware and not without investment.

P.S. The paper includes results of QNX Neutrino with a microkernel and didn't perform too bad despite the reputation for early microkernels having poor performance. Ironically, microkernels are known for having better security than monolithic kernels. The paper states the following.

Quote:

One of the advantages of the microkernel over other types of kernels is that even when a critical error happens, such as in the filesystem for example, all the remaining parts of the system are not influenced. This means that the microkernel architecture offers a more robust environment than the ones used in other operating systems, although its problem is the overhead caused by the memory protection [Timmerman 2001] which have to be used very frequently, as all the parts of the system are isolated.

I did have ideas how to avoid much of that overhead but it falls on deaf ears around here.