On Wed, Dec 2, 2020 at 3:12 PM Andrew Warkentin <[email protected]> wrote: > > 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
