Figure out a better way to associate Rec with Rd about islet HOT 2 CLOSED

// (1) pub struct Rec
pub struct Rec {
    rd: usize,  // the physical address of  rd.
    vcpuid: usize,
    ripas: Ripas,
    id: id,    // we can use this ID as it's guranteed "rd" will not be destroyed as long as this Rec is in use.
}

// (2) we can put "Rec" inside "Granule"

// (3) get Rec (getter)
:: API-style-1
get_granule_object(addr, Rec (type?)) {
    // 1. check if the granule at addr is valid and Rec.
    // 2. If so, it returns something like "PointerMutGuard" in which it is able to directly maps "struct Rec".
    //      -- it increases Rec's reference count itself
    //      -- in order to avoid being destroyed when REC_DESTROY called.
   //       -- after guard ends, it decreases Rec's reference count.
}

:: API-style-2
GranuleObjectPointer  --> it's like HostPointer but related to granule object (Rd/Rec/Run/Data/...)
// can we reuse "HostPointer" for both HostPointer and GranuleObjectPointer, it seems possible.

pub struct GranuleObjectPointer<T> {   // T: struct Rec, struct Rd, ...
    /// pointer to physical region
    ptr: *const T,  // struct Rec, struct Rd,
    /// page_map to map or unmap `ptr` in RMM
    page_map: PageMap,  // --> is it needed??
}

pub fn validate<'a>(&'a self) -> Option<GranuleObjectPointerGuard<'a, T>> {
    // 1. check if the granule at addr is valid and Rec.
    get_granule(...)   // per-struct Accessor needed??? Accessor for Rec...

    if is_valid() {
        increment_reference_count(granule);
        return Guard;
    }
}
fn drop(&mut self) {
    decrement_reference_count();
}
--> it seems fitting in "temporal access" nicely, but not sure for "long-lived ones, like Rec, Rd".
--> for long-lived structs, who holds "GranuleObjectPointerGuard"?