PRs for common generic type 'AddrSpace<..>'

[shilei-massclouds]

We try to have axvisor and oscomp/starry-next to use common generic type 'AddrSpace<M,PTE,H>'.
There're 7 PRs across 3 organizations, including arceos-hypervisor, oscomp, arceos-org and mivik.
The order of these PRs is IMPORTANT.
NOTE: Last time, we have 9 PRs. According to comments from JYK, use 'Into' rather than adding debug constrains, so remove fixes for 'page_table_multiarch' and 'mivik_page_table_multiarch' . See below:

PRs

1. [arceos-org]: Create repo 'npt_multiarch' which is a copy of 'npt' in axaddrspace.
   https://github.com/arceos-org/npt_multiarch

2. [arceos-hypervisor/axaddrspace]: Use 'npt' in arceos-org/npt_multiarch instead.
   Use external npt and common generic type 'AddrSpace<..>' axaddrspace#12
   commit '9432388'

[REMOVED] [page_table_multiarch]: Add 'Debug' and 'LowerHex' constrains to PagingMetaData::VirtAddr.

3. [arceos-hypervisor/axaddrspace]: Refactor AddrSpace generic type as 'AddrSpace<ArchPagingMetatData, ArchPTE, H>'.
   Use external npt and common generic type 'AddrSpace<..>' axaddrspace#12
   commit '1a009bc'

4. [arceos-org]: Create repo 'aspace_generic' which is a copy of 'AddrSpace' generic-type in axaddrspace.
   https://github.com/arceos-org/aspace_generic
   commit 'f6fbe035'

5. [arceos-hypervisor/axaddrspace]: Use 'AddrSpace' in arceos-org/aspace_generic instead.
   Use external npt and common generic type 'AddrSpace<..>' axaddrspace#12
   commit 'a443fef7'

[REMOVED] [mivik_page_table_multiarch]: Add 'Debug' and 'LowerHex' constrains to PagingMetaData::VirtAddr.

6. [arceos-org/aspace_generic]: Combine features of 'AddrSpace' from 'axmm' which is used by starry-next.
   https://github.com/arceos-org/aspace_generic
   commit '751838b5' combines features from both parts;
   commit 'd3086907' avoids modifying page_table_multiarch to add 'Debug', just use Into] to print debug info.

7. [oscomp/arceos]: Use 'AddrSpace' in arceos-org/aspace_generic instead.
   Use 'AddrSpace' in arceos-org/aspace_generic instead. oscomp/arceos#37

The 6th PR

For the 6th PR，we need to resolve the collisions of AddrSpace between axaddrspace(used by axvisor) and axmm (used by starry-next).

1. Aspace root:

1.1 map_linear

Both use 'validate_region' from starry.

1.2 map_alloc

Both use 'validate_region' from starry.

1.3 unmap

Both use 'validate_region' from starry.

1.4 handle_page_fault

Coding in the same way with only minor differences. Keep implementation from axvisor.

2. Aspace backend root:

2.1 Clone

Implement method 'clone' instead of '#[derive(Clone)]'.

2.2 protect

Mothod 'protect' in axvisor is a stub, so use implementation from starry.

3. Aspace backend/linear:

3.1 map_linear

Starry handles 'tlb' in addition, so use implementation from starry.

3.2 unmap_linear

4. Aspace backend/alloc:

4.1 map_alloc

When [populate] is false:

Starry does nothing here and maps entries on demand in 'handle_page_fault_alloc'.
Axvisor maps empty entries here and remaps entries on demand in 'handle_page_fault_alloc'.

I agree with starry.

4.2 unmap_alloc

Starry handles 'tlb' in addition, so use implementation from starry.

4.3 handle_page_fault_alloc

Use implementation from starry, refer to 'map_alloc'.

[AsakuraMizu]

Some notes on:

4.1 map_alloc

When [populate] is false:

Starry does nothing here and maps entries on demand in 'handle_page_fault_alloc'.

This change was introduced by oscomp/arceos#11, before we had arceos-org/page_table_multiarch#17. But for now, this is just a design difference and should not lead to wrong behavior.

[shilei-massclouds]

Some notes on:

4.1 map_alloc
When [populate] is false:
Starry does nothing here and maps entries on demand in 'handle_page_fault_alloc'.

This change was introduced by oscomp/arceos#11, before we had arceos-org/page_table_multiarch#17. But for now, this is just a design difference and should not lead to wrong behavior.

Yes. They're all right. I just select one of them for collisions.

[ZCShou]

长期未更新