On Wed, Dec 2, 2020 at 3:12 PM Andrew Warkentin
Am I correct to assume that support for running 32-bit code on a 64-bit kernel using compatibility mode rather than virtualization and support for (presumably limited) direct system calls from VMs, bypassing any user-mode VMM (using something like Xen's trampoline page) wouldn't be accepted into seL4?
These are yet more things that I am going to want at some point and can't think of any other way to do them (besides adding them to the kernel) without significant penalties to hardware compatibility (in the case of the 32-bit support; while UX/RT will mostly be focused on 64-bit systems, it will support 32-bit Linux programs in its compatibility layer) or performance (in the case of direct kernel traps from VMs; I am planning to write a dynamic general-purpose hypervisor to go with UX/RT eventually, and adding an extra trap into the VMM on every IPC would likely add a fair bit of overhead).
I'm not aware of any purely scientific/technical reason why this wouldn't be accepted. Running a user app in 32-bit mode on a 64-bit operating system as a hardware feature isn't something that seL4 has an opinion about allowing or restricting. It's more an issue about whether it would be high enough in a priority-ordered list to justify the costs of developing and supporting. If someone could demonstrate that this cost is actually pretty low and worked towards a proposal to add it, then it would still be possible.
_______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems