对AddrSpace整合的方案

[shilei-massclouds]

方案一

AddrSpace泛型作为单独的组件，带三个泛型参数。

axvisor/arceos/starry分别在顶层填充泛型模板以实例化：

• 两个页表组件pagetable_multiarch和npt_multiarch与axaddrspace之间解耦。
• paginghandler也由axvisor/arceos/starry在顶层决定如何实现。

另外，npt_multiarch从原axaddrspace独立出来作为单独组件。

原来arceos中的axmm可以去掉，如果保留，也是简化实现。

优势：耦合度低，未来的可扩展性强。

缺点：泛型参数的组合填充有些麻烦，代码可读性和简单性受到一些影响。

方案二

直接把axaddrspace和axmm合并，AddrSpace完全实例化或仅保留一个Handler泛型参数，即AddrSpace<H>。

合并产生的aspace组件对pagetable_multiarch和npt_multiarch有依赖。

优势：实现简单直接，没有泛型的麻烦。

缺点：组件间有比较强的耦合性，对未来一些特殊情况的扩展有不利影响。

[ZR233]

投方案一1票，逻辑更为直观

[Azure-stars]

宏内核这边支持选用方案一，因为我们也需要考虑对 arceos 尽可能小的改动。其他的扩展接口实现在宏内核自身的扩展即可

[shilei-massclouds]

记录在合并工作中发现的问题：

1. 在starry使用新的地址空间泛型后发现arm平台不正常。排查后发现，是在aspace_generic的Cargo.toml中残留了对npt_multiarch的依赖，虽然代码中不使用，但是npt包含的默认features是default = ["arm-el2"]，它参与了features的统一计算，影响了starry使用的axmm的特性。总结：Cargo.toml中的无效依赖虽然不会引入不需要的代码，但可能引入意外features，导致意外结果。
   

2. 宏内核starry在地址空间方面和Hypervisor有比较大的差别，它的用户地址空间与ArceOS启动时的内核地址空间关联紧密，是从ArceOS启动时的内核地址空间复制出来的，而这个内核地址空间是一个全局变量。我在最初尝试时，希望不用去修改arceos/axmm，而是直接复制一份axmm在starry这一层进行修改。结果出现了两份全局的内核地址空间实例。