Update vm-memory dependency to 0.18.0

[XanClic]

Summary of the PR

Update the vm-memory dependency to 0.18.0. This PR supersedes #378.

0.18.0 is a breaking change, first and foremost because it renames the GuestMemory trait to GuestMemoryBackend, replacing it with a new GuestMemory trait that can abstract not only physical but also virtual memory, but in turn has a limited interface and requires specifying the required permissions for any memory access.

(Luckily, most memory accesses use the Bytes trait, which already implicitly specifies the access mode by way of which method is used, e.g. load() vs. store().)

This PR first changes some calls to use the methods that will still be available:

• check_range() instead of check_address()
• Specifically for virtio_queue::descriptor_utils::{Reader, Writer}::new(): Do not resolve memory accesses through guest memory regions, just collect slices through get_slices()
• For virtio_vsock::packet: Replace get_slice() by a helper function that calls get_slices() and returns an error if the given guest memory region maps to more than a single slice. This is not ideal: get_slice() has been removed to make users aware that guest memory regions may not always map to a single slice in their memory, especially for virtual memory, and this is just ignoring that. However, it shouldn’t be a regression, so support for this can be implemented later, I think. (Maybe via bounce buffers if the interface must stay compatible?)
• get_host_address() is removed; we only need it for testing, so we can just use get_single_slice().as_ptr() there, basically.

Then it bumps the vm-memory version, at which point we need to:

• Pass the required access permissions,
• Deal with get_slices() returning a Result<Iterator, E> instead of a plain Iterator,
• Get the bitmap type via GuestMemory::Bitmap instead of <GuestMemory::R as GuestMemoryRegion>::B, and
• Make the verification code’s SingleRegionGuestMemory implement GuestMemoryBackend instead of GuestMemory.

Compatibility Note

Note that users should still be able to depend on vm-memory 0.17.2+, even with vm-virtio updating to 0.18.0. This is because 0.17.2 internally depends on 0.18.0 and just re-exports all symbols, just some under different names (i.e. GuestMemoryBackend as GuestMemory).

Requirements

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

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

[XanClic]

Sorry, kani fails:

Check 4634: <vm_memory::guest_memory::GuestMemoryBackendSliceIterator<'_, queue::verification::SingleRegionGuestMemory> as std::iter::Iterator>::try_fold::<(), {closure@std::iter::Iterator::all::check<std::result::Result<vm_memory::VolatileSlice<'_>, vm_memory::GuestMemoryError>, {closure@<queue::verification::SingleRegionGuestMemory as vm_memory::GuestMemoryBackend>::check_range::{closure#0}}>::{closure#0}}, std::ops::ControlFlow<()>>.unwind.0
         - Status: FAILURE
         - Description: "unwinding assertion loop 0"
         - Location: ../../../../runner/.rustup/toolchains/nightly-2025-08-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/iter/traits/iterator.rs:2425:9 in function <vm_memory::guest_memory::GuestMemoryBackendSliceIterator<'_, queue::verification::SingleRegionGuestMemory> as std::iter::Iterator>::try_fold::<(), {closure@std::iter::Iterator::all::check<std::result::Result<vm_memory::VolatileSlice<'_>, vm_memory::GuestMemoryError>, {closure@<queue::verification::SingleRegionGuestMemory as vm_memory::GuestMemoryBackend>::check_range::{closure#0}}>::{closure#0}}, std::ops::ControlFlow<()>>

I’ll try to find out how to fix this, but probably only at the start of next year. I’m not really sure whether it can even be fixed inside of vm-virtio alone.

As far as I understand so far, it doesn’t seem to be anything in the GuestMemoryBackendSliceIterator itself, but just the fact that it is an iterator in the first place. That is, even if I make <GuestMemoryBackendSliceIterator as Iterator>::next() really simple so that it’s just the same as get_slice(), it still fails:

fn next(&mut self) -> Option<Self::Item> {
    if self.count == 0 {
        return None;
    }

    let count = self.count;
    self.count = 0;
    Some(
        self.mem
            .to_region_addr(self.addr)
            .ok_or(Error::InvalidGuestAddress(self.addr))
            .and_then(|(r, addr)| r.get_slice(addr, count))
    )
}

But limiting check_range() to a single element makes it work:

fn check_range(&self, base: GuestAddress, len: usize) -> bool {                    
    // get_slices() ensures that if no error happens, the cumulative length of all slices     
    // equal `len`.                                                                
    self.get_slices(base, len).take(1).all(|r| r.is_ok())
}

With take(2), it fails again, regardless of whether it’s the original GuestMemoryBackendSliceIterator implementation, or the simplified one above. So it just seems to dislike iterating as a whole, regardless of what the iterator does.

[stefano-garzarella]

I’ll try to find out how to fix this, but probably only at the start of next year. I’m not really sure whether it can even be fixed inside of vm-virtio alone.

Don't worry at all, take your time, and thank you very much for this PR!
CCing @MatiasVara @priyasiddharth for an help on kani proof.

[XanClic]

Fixed it (I hope it’s acceptable) by overriding the provided check_range() method: get_slices() will only ever return a single slice, because it’s physical memory and there is only a single region, so we can assert that and check that slice.