Add support for coalesced MMIO (`KVM_CAP_COALESCED_MMIO` / `KVM_CAP_COALESCED_PIO`)

[00xc]

Summary of the PR

Add support for coalesced MMIO. This performance feature allows guest writes to port and memory space to not trigger VM exits. Instead, the kernel will write an entry into a shared ring buffer for each access, which userspace must consume. The ring buffer is mapped at a certain offset in the vcpu's file descriptor.

In order to enable this capability, introduce the KvmCoalescedIoRing struct, which will act as a safe wrapper around the raw mapping of the ring buffer. Since users may not want to use coalesced MMIO, or it might not be available, store it as an Option in the VcpuFd struct.

Add two tests as well for the newly added code.

The public API consists of:

• A couple of capabilities:
  • Cap::CoalescedMmio (KVM_CAP_COALESCED_MMIO)
  • Cap::CoalescedPio (KVM_CAP_COALESCED_PIO).
• Methods to register and unregister addresses that will use this feature:
  • VmFd::register_coalesced_mmio() (KVM_REGISTER_COALESCED_MMIO ioctl).
  • VmFd::unregister_coalesced_mmio() (KVM_UNREGISTER_COALESCED_MMIO ioctl).
• A shared ring buffer (mapped with VcpuFd::map_coalesced_mmio_ring()).
• A safe method to read from the ring (VcpuFd::read_coalesced_mmio()).

Requirements

Before submitting your PR, please make sure you addressed the following requirements:

• [X] All commits in this PR are signed (with git commit -s), and the commit message has max 60 characters for the summary and max 75 characters for each description line.
• [X] All added/changed functionality has a corresponding unit/integration test.
• [X] All added/changed public-facing functionality has entries in the "Upcoming Release" section of CHANGELOG.md (if no such section exists, please create one).
• [X] Any newly added unsafe code is properly documented.

[00xc]

@JonathanWoollett-Light addressed your suggestions in the newer version, except the ones about using function mnemonics. Regarding that, isn't that change out of scope for this PR? It would add a new dependency and we would still have a bunch of tests which use raw bytes as assembly code. I'd rather work on that change in a separate PR.

[00xc]

By the way the code can also properly be assembled with that crate's CodeAssembler, e.g.

let mut asm = CodeAssembler::new(16).unwrap();
asm.out(0x2c, al).unwrap();
asm.hlt().unwrap();
asm.out(0x2c, al).unwrap();
asm.hlt().unwrap();
let code = asm.assemble(base_addr).unwrap();

[JonathanWoollett-Light]

@JonathanWoollett-Light addressed your suggestions in the newer version, except the ones about using function mnemonics. Regarding that, isn't that change out of scope for this PR? It would add a new dependency and we would still have a bunch of tests which use raw bytes as assembly code. I'd rather work on that change in a separate PR.

Yeah this makes sense.

[00xc]

Rebased on main and fixed conflicts

[00xc]

Gentle ping for reviewers :)

[JonathanWoollett-Light]

@00xc Can you please resolve the merge conflicts, after this LGTM.

[00xc]

Rebased on main and fixed conflicts