GuestPtr vs UserPtr request for clarification and Documentation

[deeglaze]

In #653 I'm attempting to add arbitrary length reads and writes to contiguous guest memory that is outside the purview of both the SVSM kernel and SVSM userspace.

Whereas SVSM controls the page tables for its own userspace, it doesn't control the page tables for GUEST_VMPL. This is where I understand page mapping guards to be important, to directly map physical memory. The mm::memory::valid_phys_address check ensures that an address is outside memory claimed for SVSM use (both kernel and userspace).

In this commit, (GitHub doesn't point to the PR that introduced it, so I can't find discussion around it)
3121843 I'm confused about wrapping GuestPtr. It seems to me that SVSM user space reads and writes should trap and return the equivalent of -EFAULT when a read or write goes bad, rather than require the pages to be mapped ahead of time in a guard. It also doesn't make sense to have a construct that checks physical address range since user vs. kernel should be determined by a supervisor bit in the PTE that stac/clac change the faulting behavior for.

Whereas the fault-checking read/write is there in copy_bytes for both GuestPtr and UserPtr, I think we should have separate concepts. First, GuestPtr and UserPtr are translated to constructs on top of slices so we can read/write a dynamically sized amount of memory (Vectors).

The GuestPtr and UserPtr type bounds do not account for the direct byte representation needed when crossing ABI boundaries. We don't always need a FromBytes bound and IntoBytes bound, so reads and writes need an asymmetric API.

/cc @vijaydhanraj for comment about guestmem UserPtr in case I misunderstand