Re: Hyplets - User Space Interrupts

The code and paper are available at sourceforge at:
https://sourceforge.net/p/hyplet-pi3/code/ci/master/tree/hyplets-multiple-exception.pdf
  

On 09/06/18 15:57, Marc Zyngier wrote:

> On Fri, 08 Jun 2018 13:55:02 +0100,
> raz wrote:
>> We would like to present ARM hyplets. Hyplets are an innovative way
>> to code interrupt service routines under ARM.  Hyplets provide high
>> performance, security, running time predictability ,an RPC mechanism
>> and a possible solution for the priority inversion problem. Hyplets
>> uses special features of ARM hypervisor memory architecture.  We
>> demonstrate Hyplets implementation in the C programming language on
>> ARMv8 platform and under the Linux kernel.  We provide performance
>> measurements, use cases and security scenarios.
>>
>> Hyplets are based on the concept of a delicate separation within a
>> running process. Instead of running multiple operating systems
>> kernels in order to segment and divide the system resources, the
>> hyplet divides the Linux process into two execution modes. One part
>> of the process would execute in an isolated, non-interrupted
>> privileged safe execution environment while other parts of the
>> process would execute in a regular user mode. However, both
>> execution modes run in the same Application processors.
> I haven't had a chance to look at the code (the provided URL just
> gives me a 502), but mentioning userspace-controlled code at EL2 and
> security in the same sentence sounds a bit... odd.
>
>
>> The trivial approach of migrating code to kernel space to improve
>> performance requires a high level of kernel programming skills.
>> Alternatively, if we try to access a user space code from the ISR,
>> it would probably require a context switch because there is no
>> guarantee that the current process in the processor is the one with
>> hyplet code. We needed to make sure that the hyplet code is always
>> accessible and this could be achieved only by disabling evacuation
>> of the hyplet code and data from the current translation table. So,
>> we we chose to use TTBR0_EL2 ( the translation table register) to
>> constantly hold the hyplet code.  In order to map user space tasks
>> we modified the Linux ARM-KVM mappings infrastructure to map a user
>> space code in tandem with some kernel space data.
> So writing kernel code is hard, but writing hypervisor-level is much
> easier? I'll try to remember that! ;-)
>
> Again, I couldn't look at your code nor any data, but have you
> considered using the KVM API to run code as a guest at EL1 instead? I
> know of at least one project doing so to get the kernel out of the way
> and get fast timer access.
>
> Thanks,
>
> 	M.