Identity of rmi::Interface

[bokdeuk-jeong]

It appears that rmi::Interface's identity has to be clarified.

1. Name
   Its name 'rmi::Interface' indicates this is the place for receiving and handling RMM requests first hand, while it actually is implementing required functionalities and is called at the rmi module in rmm/src/rmi as subroutines.

2. Role
   RMI (rmi::Interface) initially intended to have the role of some kind of mediator or anchor to access a realm or a vcpu, but it currently contains detail implementation. Now, It needs to rethink the role of RMI and rmm/src/rmi.

• Some of the detail implementation in RMI looks better to move out of RMI and be taken/implemented by other components with exposing an interface for it instead.
• Some implementation in rmm/src/rmi is also pretty much in detail too. How do you think about the role that each RMI and rmm/src/rmi should take if you redesign it?

[zpzigi754]

In my opinion, rmm/src/rmi/mod.rs's Interface should have almost the same list as the list of RMI commands for the consistency and unity. In this direction, the initial validity checks can be conducted in the event handler of listen! macro while the core logic is handled inside the Interface's implementation. Then, Interface would be defined as the gate of accessing the core logic (== detailed implementation) of RMIs. The representing example of following this rule is rtt_create while the counter-example is set_reg.

Another possible direction is that Interface trait itself can be entirely removed and replaced as functions, because the trait itself was mainly used for accessing armv9a from monitor.

[bitboom]

Another possible direction is that Interface trait itself can be entirely removed and replaced as functions, because the trait itself was mainly used for accessing armv9a from monitor.

I vote to this.
rmi::Interface introduced for armv9a crate. I think listen macro is enough for receiving and handling RMM requests first hand. And we could call proper functions directly in listen body.

[bokdeuk-jeong]

• I agree with bitboom's. As the name rmm/src/rmi/ itself implies, I think all the RMM spec related part needs to be in rmm/src/rmi/.
• I also totally agree with zpzigi754's idea about placing the initial validity checks within the event handler of listen! macro.
  (I had also felt the need for this. :) )
  To summarize, do the validity checks in the listen! handler, but remove rmi::Interface and place existing rmi::Interface code under rmm/src/rmi.|

Utimately, by handling Arm's RMM spec specific implemenation at rmm/src/rmi, and we make the role of each component in Islet be clearer. Moreover, we will have Islet more flexible with interfacing any type of specifications. rmm/src/realm will be the common and basic unit for all other type of interfaces for future use. (e.g. some common interface defined by us or others for IoT/wearable)

[nook1208]

To summarize, do the validity checks in the listen! handler, but remove rmi::Interface and place existing rmi::Interface code under rmm/src/rmi

I also agree with this idea. In fact, I was thinking that some of the functions in the interface could potentially be removed from it or moved to other place.

[jinbpark]

I took a quick look at the current implementation and comments on this thread.
I totally agree with @bokdeuk-jeong 's concerns and @zpzigi754 's idea.

A little extension to this discussion, in my opinion:

• listen! macro: validity checks and granule management codes (not sure at this point if we can handle all granule-related codes here for all RMIs) and memory mapping codes (RMM's stage-1 table mapping)
• core logic (separate function): everything else, but its capability can be limited by which listen! macro gives.
  e.g., We can enforce that core logic functions are not allowed to make an additional page table mapping (+ granule-change apis). They only can access memory that listen! macro gives. It's like listen! macro is a control tower to decide what resources are going to be allowed for core logic functions to use. You can see this as a rust-based isolation feature.

Interface trait itself can be entirely removed and replaced as functions

I like this idea, too. But I think we need to figure out a generic way to access from monitor to armv9, which is not limited to this rmi case.

[zpzigi754]

Reflected on #235 and #251.