About who should take care of HostPhysAddr and GuestPhysAddr

[hky1999]

From the perspective of an ordinary OS address space, we only need to consider the concepts of physical address and virtual address.
That is, VirtAddr and PhysAddr from memory_addr crate.

However, as a hypervisor, we need to take care of two-stage address translation, which brings the concept of GuestVirtAddr and GuestPhysAddr, along with HostVirtAddr and HostPhysAddr.

I am currently working on refactor the address space management for guest VM in axvm crate.

I find that axvcpu has definition of GuestVirtAddr and GuestPhysAddr, like this:

/// Guest virtual address.
pub type GuestVirtAddr = usize;
/// Guest physical address.
pub type GuestPhysAddr = usize;

Also, axvm also has its own definition of GuestVirtAddr and GuestPhysAddr (althrough it simply regards them as usize).

/// Guest virtual address.
pub type GuestVirtAddr = usize;
/// Guest physical address.
pub type GuestPhysAddr = usize;
/// Host virtual address.
pub type HostVirtAddr = VirtAddr;
/// Host physical address.
pub type HostPhysAddr = PhysAddr;

During my refactor process, I hope to integrate them into the axaddrspace crate, like this:

use memory_addr::{PhysAddr, VirtAddr};

/// Guest virtual address.
pub type GuestVirtAddr = VirtAddr;
/// Guest physical address.
pub type GuestPhysAddr = VirtAddr;
/// Host virtual address.
pub type HostVirtAddr = VirtAddr;
/// Host physical address.
pub type HostPhysAddr = PhysAddr;

Because axaddrspace essentially needs to manage the translation between GuestPhysAddr to HostPhysAddr, which is VirtAddr to PhysAddr from the aspect of memory_addr crate.

My question is, from the perspective of arceos-vmm app, does it need to take care of HostPhysAddr and GuestPhysAddr, or does it only need to take care of the VirtAddr and PhysAddr perspective?

Note: we need to implement AxVMHalImpl for axvm's AxVMHal Trait in arceos-vmm app.

I just use memory_addr::{PhysAddr, VirtAddr} in arceos-vmm because I think only axvm crate should care for HostPhysAddr and GuestPhysAddr.

[hky1999]

@aarkegz

[aarkegz]

reading……

[aarkegz]

An axaddrspace is undoubtedly necessary.

During my refactor process, I hope to integrate them into the axaddrspace crate, like this:

use memory_addr::{PhysAddr, VirtAddr};

/// Guest virtual address.
pub type GuestVirtAddr = VirtAddr;
/// Guest physical address.
pub type GuestPhysAddr = VirtAddr;
/// Host virtual address.
pub type HostVirtAddr = VirtAddr;
/// Host physical address.
pub type HostPhysAddr = PhysAddr;

⬆️Why is GuestPhysAddr VirtAddr?

There's one more thing: in rust, type alias does not create new types. Aliasing both GuestVirtAddr and HostVirtAddr to VirtAddr means they can be used interchangeably, which sounds a little bit weird.

[aarkegz]

Ok, it may appear in the next release. Anyone wanna do this?

I can implement this and axaddrspace

axaddrspace has been implemented and will be published soon.

Oh, that's nice

[equation314]

We just need to add an association VA type in PagingMetaData.

[hky1999]

Maybe it can be made an associated type of PTE?

@aarkegz You can improve this,

[aarkegz]

We just need to add an association VA type in PagingMetaData.

🫡👌

[hky1999]

Ok, it may appear in the next release. Anyone wanna do this?

I can implement this and axaddrspace

axaddrspace has been implemented and will be published soon.

axaddressspace has been published, currently only works in x86_64 is tested.

I will open a new discussion soon about questions related to memory management.

[aarkegz]

Updates allowing generic virtual address have been merged into page_table_multiarch. I think it's time to update axaddrspace to introduce new GPA and GVA types. @hky1999

[hky1999]

Yes, I am working on it, sorry for delay

[hky1999]

Updates allowing generic virtual address have been merged into page_table_multiarch. I think it's time to update axaddrspace to introduce new GPA and GVA types. @hky1999

This is more complicated than we throught.

The same modification we did to page_table_multiarch (adding an association VA type) should be deployed in both memory_set, for example:

// memory_set/src/area.rs
pub trait MappingBackend<F: Copy, P>: Clone {
    /// What to do when mapping a region within the area with the given flags.
    fn map(&self, start: VirtAddr, size: usize, flags: F, page_table: &mut P) -> bool;
    /// What to do when unmaping a memory region within the area.
    fn unmap(&self, start: VirtAddr, size: usize, page_table: &mut P) -> bool;
}

[hky1999]

The complexity:

in page_table_multiarch, VA type in PagingMetaData can be easily covered by

type VirtAddr: Into<usize> + From<usize> + Copy;

however, in memory_set, VirtAddr's as_usize() is used almost everywhere, it's a const function which makes it impossible to use a trait to describe the behavior of VirtAddr.

The problem is, how can we make parameter types like memory_addr::VirtAddr in memory_set more generic, so memort_set can be used in hypervisor's guest address space management.

[hky1999]

related PR:
arceos-umhv: #15
axaddrspace: arceos-hypervisor/axaddrspace#3

@aarkegz @equation314