Streamlining the process of the realm managment

[bokdeuk-jeong]

Rd vs Realm, Rec vs Vcpu, they have the same goal with mananging a realm and its vcpus respectively. I would like to share my thoughts that there should be a streamlining and disscuss how these can be resolved.

1. First, there are some redundancies with the management. Removing one of them seems better.

For example,

pub struct Realm<T: Context> {
    id: usize,
    pub vmid: u16,
    pub state: State,
    pub vcpus: Vec<Arc<Mutex<VCPU<T>>>>,
    pub page_table: Arc<Mutex<Box<dyn IPATranslation>>>,
    pub measurements: [Measurement; MEASUREMENTS_SLOT_NR],
}

 pub struct Rd {
    realm_id: usize,
    state: State,
    rtt_base: usize,
    ipa_bits: usize,
    rec_index: usize,
    s2_starting_level: isize,
    hash_algo: u8,
} 

• identical fields or the fields with same purpose
  • realm_id vs vmid (or id?)
  • state in both Realm and Rd
• lock
  When we access Rd, locking is involved. So is Realm. The locks itself are diffent objects, but we are indeed locking twice for managing a single realm management request. (This is the same as the scenario with Rec and Vcpu.)

2. The way that realm execution contexts are referenced are different. Keeping
   Realm has a field to reference its realm execution contexts, vcpus. To access vcpus, we have to go through realm first.
   On the other hand, we directly take reference Rec at rmi.
   What if Rec could directly reference Vcpu?

3. Do we even need to have sperate data structures, Realm and Rd, for the same purpose?
   If yes, we need to define each role and keep the only things that conforms the definition.
   Maybe this needs to be answered first; "Is islet going to only support Arm RMM interface?"

[bitboom]

I think we are not going to only support Arm RMM interface.

But, At this point, it would be better to follow the RMM interface because there is no particular reason to take it separately.
If we are following the specifications, there is no confusion at least between our implementation and the specifications in terms of terminology.

My suggestion is

1. Move Realm and Vcpu fields to Rd and Rec
2. If we need additional field like vmid add the comment

[zpzigi754]

Good to raise this dicussion topic! I guess that everyone would agree on removing duplicate fields. I agree on @bitboom's direction: integrating Realm and Rd as well as Vcpu and Rec. I think that we don't have to maintain similar data structures for almost the same purpose.

By the way, I am not sure whether we should consider the possibility that this platform is extended for supporting other platforms. I personally perfer that islet targets only Arm CCA.

[zpzigi754]

Reflected on #312 and #330.