Better abstractions for dealing with host addresses

[DemiMarie]

Right now, using this crate requires extracting raw pointers to host memory and passing them to various ioctls. This is very error-prone: see cloud-hypervisor/cloud-hypervisor#7129 for a partial fix to the problems I have seen in Cloud Hypervisor.

A much better approach would be to have various types that owned the host memory, or at least a reference to it. One would obtain this type by mapping memory into a guest, a VFIO container, or something else. Dropping the type would unmap the memory and release the reference. The host address of the memory would not be directly available to applications, preventing it from being misused.

Another option would be to instead have the memory regions be responsible for unmapping the data when dropped. This requires hard-coding VFIO and the hypervisor, but that might be an acceptable compromise for a simpler design.

CC @alyssais who reviewed cloud-hypervisor/cloud-hypervisor#7129, of which this is a continuation.

[bonzini]

Hi, I'm not sure I understand the issue. Aren't Bytes<>, VolatileSlice<>, etc. already "references to host memory"?

[DemiMarie]

The problem is that the kernel APIs don’t use those types. They use raw pointers, and I believe the kernel implicitly reference counts pages. For instance, I believe unmapping memory doesn’t free it if there is still a reference to it from a guest or a VFIO container. If the guest balloons out some pages and they are not unmapped from the VFIO container, the VMM has essentially leaked the memory. Also, I’m not sure what happens if one tries to map memory into a guest or VFIO container while there is already a conflicting mapping of that address. Does it fail? Overwrite the existing mapping? I'm not sure, and I suspect this indicates a bug in the caller.

VolatileSlice<> is just a reference. It doesn’t own anything. This issue is about is something that actually owns the memory and knows about all the places a given page is currently mapped. It can thus ensure that unmapping a page from the guest also unmaps it from all of the other places it needs to be unmapped from, like a VFIO container or vhost device. It can also enqueue commands to vhost-user devices to unmap the memory from there. Furthermore, it can ensure that memory is mapped in the host as long as it is mapped in the guest, unless the guest is protected and the memory must not be mapped in the host.