Implement frame metadata and refactor most usages of frames

[junyang-zh]

Found a patch named frame_meta_v2.patch on my pants. Seems that it implements the frame metadata.

EDIT: I am trying to make commits in this PR atomic.

• Implement basic FrameMeta with one counter and use it for VmFrame;
• Use the metadata to improve the page table;
• Expose the cursor to the framework user, addressing The APIs of VmSpace are vulnerable to race conditions #681;
• Remove VmFrameVec;
• Rename VmFrame to Frame and refactor PAGE_SIZE usages;
• Refactor VmSegment to Segment;
• Rename aster_frame::vm to aster_frame::mm;
• Mark the memory region information in the metadata.

EDIT: I am marking the first commit ready for review. I may continue working on the following commits.

EDIT: The page table is improved with the metadata now. However I didn't observe significant performance improvement and it is even slightly worse (the time mapping 273,255 untracked frames (~1G) at a time in release mode is ~73ms compared to original ~56ms). Only the memory usage is improved. I suspect that the original overhead behaves like a cache from reading PTEs.

EDIT: I refactored the cursor. After heavy manual optimization, the time mapping 273,255 untracked frames in release mode dropped from ~73ms to ~42ms, and is faster than the original ~56ms. Yes!

EDIT: I removed some goals of this PR.

[junyang-zh]

I may post the justification for some utter changes here:

Removal of the VmIo implementation of VmSpace

Efficient Reading/Writing in a virtual memory space can only be done if it is activated. This behavior is not aligned with the definition of VmIo, which don't have this extra requirement. Also it is not actually useful now, removing it is not a big problem. We should provide an efficient R/W abstraction to the user space in the future.

Frame handle as an any-level frame

Well, you can get a handle to a mapped frame while querying over the page table by virtual addresses. If Frames are only base pages, you need an extra enum for returning the results. The current design provides a set of inherently elegant APIs. We can also ensure Frame being mappable if virtual address is aligned. But if use Segment for huge pages, there would be extra checks and the user may not sure if the page is mapped as a huge one.

The level is also encoded in the virtual address of the metadata, so there's no overhead in the handle. The users can always make static assertions of the size of the frame if they are clear about how it is created managed. Although the aster-nix is currently ignorant about huge frames, it also works well and no extra overhead is brought since page_size(1) is a constant and aster-nix can safely regard all of them as base pages (frame.size() == page_size(1) && frame.level == 1 as an invariant).

Removal of VmFrameVec

Honestly the only 2 pro of this is doing batch mapping/IO(R/W). But you have a cursor to do actual batch mapping. The R/W implementation is trivial also. So why not Vec<Frame> when needed?

[tatetian]

Most of the code looks good. But the Page::drop method needs to be revised extensively, I suppose. See my detailed comments above.

[junyang-zh]

Why is adding a copy_handle method more preferable than implementing the Clone trait?

Because there are two behaviors of a clone in the page table context. The "deep copy" is to allocate a new page and recursively copy all the children; while the "shallow copy" copies the handle and increments the reference count. Implementing the Clone trait makes this distinction dubious. So I choose to implement both deep and shallow copy by methods.

And yes. I am skeptical about all code locations where the concept of "handle" is mentioned.

The concept of handle is good but as the confusion it has brought to you I think further comments in the code is needed. Perhaps there would be naming problems. Arc is definitely a handle to the underlying data type, with a good naming. But PageRc(PageTableNodeRc, SegmentRc, ...) seems an awkward copy cat naming. Developers won't use other things than Page to access a page either. So Page as a page handle would seemingly be a nice concept. There may be better alternatives but I haven't thought of one yet.

[junyang-zh]

I think the names forget and restore should be re-considered.

For forgetting and restoring the page handle, the naming is indeed not appropriate. I've renamed them into into_raw and from_raw. They still operate on Paddr for the following reasons: Arc::<T>::from_raw and Arc::<T>::into_raw operates also on *const T rather than *const ArcInner. A Paddr points to a page, which is sound.

Also, the Page::from_raw and Page::into_raw on Paddr are very helpful for page table implementations, since you need to into_raw a page table node and store the Paddr in a PTE/cr3.

For xarray FrameRef implementations, it's now behaving like a transmute, giving out *const MetaSlots.

[tatetian]

I think the names forget and restore should be re-considered.

For forgetting and restoring the page handle, the naming is indeed not appropriate. I've renamed them into into_raw and from_raw. They still operate on Paddr for the following reasons: Arc::<T>::from_raw and Arc::<T>::into_raw operates also on *const T rather than *const ArcInner. A Paddr points to a page, which is sound.

Also, the Page::from_raw and Page::into_raw on Paddr are very helpful for page table implementations, since you need to into_raw a page table node and store the Paddr in a PTE/cr3.

For xarray FrameRef implementations, it's now behaving like a transmute, giving out *const MetaSlots.

I am satisfied with the refactored version.

[tatetian]

LGTM. Thanks for the contribution!