Skip to content

Commit 20ec405

Browse files
committed
The great rename
Rename GuestMemory to GuestMemoryBackend, IoMemory to GuestMemory. This allows users of vm-memory to be aware of access permissions for memory, with no change to callers that just use the `Bytes` interface. Signed-off-by: Paolo Bonzini <[email protected]>
1 parent 4032ff1 commit 20ec405

File tree

12 files changed

+129
-129
lines changed

12 files changed

+129
-129
lines changed

DESIGN.md

Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -74,8 +74,8 @@ of the VM using the following traits:
7474
`u64` is used to store the the raw value no matter if it is a 32-bit or
7575
a 64-bit virtual machine.
7676
- `GuestMemoryRegion`: represents a continuous region of the VM memory.
77-
- `GuestMemory`: represents a collection of `GuestMemoryRegion` objects. The
78-
main responsibilities of the `GuestMemory` trait are:
77+
- `GuestMemoryBackend`: represents a collection of `GuestMemoryRegion` objects. The
78+
main responsibilities of the `GuestMemoryBackend` trait are:
7979
- hide the detail of accessing physical addresses (for example complex
8080
hierarchical structures).
8181
- map an address request to a `GuestMemoryRegion` object and relay the
@@ -88,14 +88,14 @@ access VM's physical memory and not on the implementation of the traits.
8888

8989
### Backend Implementation Based on `mmap`
9090

91-
Provides an implementation of the `GuestMemory` trait by mmapping the VM's physical
91+
Provides an implementation of the `GuestMemoryBackend` trait by mmapping the VM's physical
9292
memory into the current process.
9393

9494
- `MmapRegion`: implementation of mmap a continuous range of physical memory
9595
with methods for accessing the mapped memory.
9696
- `GuestRegionMmap`: implementation of `GuestMemoryRegion` providing a wrapper
9797
used to map VM's physical address into a `(mmap_region, offset)` tuple.
98-
- `GuestMemoryMmap`: implementation of `GuestMemory` that manages a collection
98+
- `GuestMemoryMmap`: implementation of `GuestMemoryBackend` that manages a collection
9999
of `GuestRegionMmap` objects for a VM.
100100

101101
One of the main responsibilities of `GuestMemoryMmap` is to handle the use
@@ -127,18 +127,18 @@ let result = guest_memory_mmap.write(buf, addr);
127127
When using an IOMMU, there no longer is direct access to the guest (physical)
128128
address space, but instead only to I/O virtual address space. In this case:
129129

130-
- `IoMemory` replaces `GuestMemory`: It requires specifying the required access
130+
- `GuestMemory` replaces `GuestMemoryBackend`: It requires specifying the required access
131131
permissions (which are relevant for virtual memory). It also removes
132132
interfaces that imply a mostly linear memory layout, because virtual memory is
133133
fragmented into many pages instead of few (large) memory regions.
134-
- Any `IoMemory` still has a `GuestMemory` inside as the underlying address
134+
- Any `GuestMemory` still has a `GuestMemoryBackend` inside as the underlying address
135135
space, but if an IOMMU is used, that will generally not be guest physical
136136
address space. With vhost-user, for example, it will be the VMM’s user
137137
address space instead.
138-
- `IommuMemory` as our only actually IOMMU-supporting `IoMemory`
138+
- `IommuMemory` as our only actually IOMMU-supporting `GuestMemory`
139139
implementation uses an `Iommu` object to translate I/O virtual addresses
140140
(IOVAs) into VMM user addresses (VUAs), which are then passed to the inner
141-
`GuestMemory` implementation (like `GuestMemoryMmap`).
141+
`GuestMemoryBackend` implementation (like `GuestMemoryMmap`).
142142
- `GuestAddress` (for compatibility) refers to an address in any of these
143143
address spaces:
144144
- Guest physical addresses (GPAs) when no IOMMU is used,
@@ -166,8 +166,8 @@ with minor changes:
166166
- `Address` inherits `AddressValue`
167167
- `GuestMemoryRegion` inherits `Bytes<MemoryRegionAddress, E = Error>`. The
168168
`Bytes` trait must be implemented.
169-
- `GuestMemory` has a generic implementation of `IoMemory`
170-
- `IoMemory` has a generic implementation of `Bytes<GuestAddress>`.
169+
- `GuestMemoryBackend` has a generic implementation of `GuestMemory`
170+
- `GuestMemory` has a generic implementation of `Bytes<GuestAddress>`.
171171

172172
**Types**:
173173

@@ -178,6 +178,6 @@ with minor changes:
178178

179179
- `MmapRegion` implements `VolatileMemory`
180180
- `GuestRegionMmap` implements `Bytes<MemoryRegionAddress> + GuestMemoryRegion`
181-
- `GuestMemoryMmap` implements `GuestMemory`
181+
- `GuestMemoryMmap` implements `GuestMemoryBackend`
182182
- `VolatileSlice` implements
183183
`Bytes<usize, E = volatile_memory::Error> + VolatileMemory`

README.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -62,7 +62,7 @@ Then add `extern crate vm-memory;` to your crate root.
6262
## Examples
6363

6464
- Creating a VM physical memory object in hypervisor specific ways using the
65-
`GuestMemoryMmap` implementation of the `GuestMemory` trait:
65+
`GuestMemoryMmap` implementation of the `GuestMemoryBackend` trait:
6666

6767
```rust
6868
fn provide_mem_to_virt_dev() {
@@ -77,7 +77,7 @@ fn provide_mem_to_virt_dev() {
7777
- Consumers accessing the VM's physical memory:
7878

7979
```rust
80-
fn virt_device_io<T: GuestMemory>(mem: &T) {
80+
fn virt_device_io<T: GuestMemoryBackend>(mem: &T) {
8181
let sample_buf = &[1, 2, 3, 4, 5];
8282
assert_eq!(mem.write(sample_buf, GuestAddress(0xffc)).unwrap(), 5);
8383
let buf = &mut [0u8; 5];

benches/guest_memory.rs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ use core::hint::black_box;
77
pub use criterion::Criterion;
88

99
use vm_memory::bitmap::Bitmap;
10-
use vm_memory::{GuestAddress, IoMemory, GuestMemoryMmap};
10+
use vm_memory::{GuestAddress, GuestMemory, GuestMemoryMmap};
1111

1212
const REGION_SIZE: usize = 0x10_0000;
1313
const REGIONS_COUNT: u64 = 256;

benches/mmap/mod.rs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@ use std::path::Path;
1717
use core::hint::black_box;
1818
use criterion::Criterion;
1919

20-
use vm_memory::{ByteValued, Bytes, GuestAddress, IoMemory};
20+
use vm_memory::{ByteValued, Bytes, GuestAddress, GuestMemory};
2121

2222
const REGION_SIZE: usize = 0x8000_0000;
2323
const REGIONS_COUNT: u64 = 8;

src/atomic.rs

Lines changed: 18 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
// Copyright (C) 2020 Red Hat, Inc. All rights reserved.
33
// SPDX-License-Identifier: Apache-2.0
44

5-
//! A wrapper over an `ArcSwap<IoMemory>` struct to support RCU-style mutability.
5+
//! A wrapper over an `ArcSwap<GuestMemory>` struct to support RCU-style mutability.
66
//!
77
//! With the `backend-atomic` feature enabled, simply replacing `GuestMemoryMmap`
88
//! with `GuestMemoryAtomic<GuestMemoryMmap>` will enable support for mutable memory maps.
@@ -15,17 +15,17 @@ use arc_swap::{ArcSwap, Guard};
1515
use std::ops::Deref;
1616
use std::sync::{Arc, LockResult, Mutex, MutexGuard, PoisonError};
1717

18-
use crate::{GuestAddressSpace, IoMemory};
18+
use crate::{GuestAddressSpace, GuestMemory};
1919

2020
/// A fast implementation of a mutable collection of memory regions.
2121
///
2222
/// This implementation uses `ArcSwap` to provide RCU-like snapshotting of the memory map:
23-
/// every update of the memory map creates a completely new `IoMemory` object, and
23+
/// every update of the memory map creates a completely new `GuestMemory` object, and
2424
/// readers will not be blocked because the copies they retrieved will be collected once
2525
/// no one can access them anymore. Under the assumption that updates to the memory map
2626
/// are rare, this allows a very efficient implementation of the `memory()` method.
2727
#[derive(Debug)]
28-
pub struct GuestMemoryAtomic<M: IoMemory> {
28+
pub struct GuestMemoryAtomic<M: GuestMemory> {
2929
// GuestAddressSpace<M>, which we want to implement, is basically a drop-in
3030
// replacement for &M. Therefore, we need to pass to devices the `GuestMemoryAtomic`
3131
// rather than a reference to it. To obtain this effect we wrap the actual fields
@@ -34,9 +34,9 @@ pub struct GuestMemoryAtomic<M: IoMemory> {
3434
inner: Arc<(ArcSwap<M>, Mutex<()>)>,
3535
}
3636

37-
impl<M: IoMemory> From<Arc<M>> for GuestMemoryAtomic<M> {
37+
impl<M: GuestMemory> From<Arc<M>> for GuestMemoryAtomic<M> {
3838
/// create a new `GuestMemoryAtomic` object whose initial contents come from
39-
/// the `map` reference counted `IoMemory`.
39+
/// the `map` reference counted `GuestMemory`.
4040
fn from(map: Arc<M>) -> Self {
4141
let inner = (ArcSwap::new(map), Mutex::new(()));
4242
GuestMemoryAtomic {
@@ -45,9 +45,9 @@ impl<M: IoMemory> From<Arc<M>> for GuestMemoryAtomic<M> {
4545
}
4646
}
4747

48-
impl<M: IoMemory> GuestMemoryAtomic<M> {
48+
impl<M: GuestMemory> GuestMemoryAtomic<M> {
4949
/// create a new `GuestMemoryAtomic` object whose initial contents come from
50-
/// the `map` `IoMemory`.
50+
/// the `map` `GuestMemory`.
5151
pub fn new(map: M) -> Self {
5252
Arc::new(map).into()
5353
}
@@ -75,15 +75,15 @@ impl<M: IoMemory> GuestMemoryAtomic<M> {
7575
}
7676
}
7777

78-
impl<M: IoMemory> Clone for GuestMemoryAtomic<M> {
78+
impl<M: GuestMemory> Clone for GuestMemoryAtomic<M> {
7979
fn clone(&self) -> Self {
8080
Self {
8181
inner: self.inner.clone(),
8282
}
8383
}
8484
}
8585

86-
impl<M: IoMemory> GuestAddressSpace for GuestMemoryAtomic<M> {
86+
impl<M: GuestMemory> GuestAddressSpace for GuestMemoryAtomic<M> {
8787
type T = GuestMemoryLoadGuard<M>;
8888
type M = M;
8989

@@ -94,14 +94,14 @@ impl<M: IoMemory> GuestAddressSpace for GuestMemoryAtomic<M> {
9494

9595
/// A guard that provides temporary access to a `GuestMemoryAtomic`. This
9696
/// object is returned from the `memory()` method. It dereference to
97-
/// a snapshot of the `IoMemory`, so it can be used transparently to
97+
/// a snapshot of the `GuestMemory`, so it can be used transparently to
9898
/// access memory.
9999
#[derive(Debug)]
100-
pub struct GuestMemoryLoadGuard<M: IoMemory> {
100+
pub struct GuestMemoryLoadGuard<M: GuestMemory> {
101101
guard: Guard<Arc<M>>,
102102
}
103103

104-
impl<M: IoMemory> GuestMemoryLoadGuard<M> {
104+
impl<M: GuestMemory> GuestMemoryLoadGuard<M> {
105105
/// Make a clone of the held pointer and returns it. This is more
106106
/// expensive than just using the snapshot, but it allows to hold on
107107
/// to the snapshot outside the scope of the guard. It also allows
@@ -112,15 +112,15 @@ impl<M: IoMemory> GuestMemoryLoadGuard<M> {
112112
}
113113
}
114114

115-
impl<M: IoMemory> Clone for GuestMemoryLoadGuard<M> {
115+
impl<M: GuestMemory> Clone for GuestMemoryLoadGuard<M> {
116116
fn clone(&self) -> Self {
117117
GuestMemoryLoadGuard {
118118
guard: Guard::from_inner(Arc::clone(&*self.guard)),
119119
}
120120
}
121121
}
122122

123-
impl<M: IoMemory> Deref for GuestMemoryLoadGuard<M> {
123+
impl<M: GuestMemory> Deref for GuestMemoryLoadGuard<M> {
124124
type Target = M;
125125

126126
fn deref(&self) -> &Self::Target {
@@ -133,12 +133,12 @@ impl<M: IoMemory> Deref for GuestMemoryLoadGuard<M> {
133133
/// possibly after updating the memory map represented by the
134134
/// `GuestMemoryAtomic` that created the guard.
135135
#[derive(Debug)]
136-
pub struct GuestMemoryExclusiveGuard<'a, M: IoMemory> {
136+
pub struct GuestMemoryExclusiveGuard<'a, M: GuestMemory> {
137137
parent: &'a GuestMemoryAtomic<M>,
138138
_guard: MutexGuard<'a, ()>,
139139
}
140140

141-
impl<M: IoMemory> GuestMemoryExclusiveGuard<'_, M> {
141+
impl<M: GuestMemory> GuestMemoryExclusiveGuard<'_, M> {
142142
/// Replace the memory map in the `GuestMemoryAtomic` that created the guard
143143
/// with the new memory map, `map`. The lock is then dropped since this
144144
/// method consumes the guard.
@@ -151,7 +151,7 @@ impl<M: IoMemory> GuestMemoryExclusiveGuard<'_, M> {
151151
mod tests {
152152
use super::*;
153153
use crate::region::tests::{new_guest_memory_collection_from_regions, Collection, MockRegion};
154-
use crate::{GuestAddress, GuestMemory, GuestMemoryRegion, GuestUsize, IoMemory};
154+
use crate::{GuestAddress, GuestMemoryBackend, GuestMemoryRegion, GuestUsize, GuestMemory};
155155

156156
type GuestMemoryMmapAtomic = GuestMemoryAtomic<Collection>;
157157

src/bitmap/mod.rs

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -4,14 +4,14 @@
44
//! This module holds abstractions that enable tracking the areas dirtied by writes of a specified
55
//! length to a given offset. In particular, this is used to track write accesses within a
66
//! `GuestMemoryRegion` object, and the resulting bitmaps can then be aggregated to build the
7-
//! global view for an entire `GuestMemory` object.
7+
//! global view for an entire `GuestMemoryBackend` object.
88
99
#[cfg(feature = "backend-bitmap")]
1010
mod backend;
1111

1212
use std::fmt::Debug;
1313

14-
use crate::{GuestMemory, GuestMemoryRegion};
14+
use crate::{GuestMemoryBackend, GuestMemoryRegion};
1515

1616
#[cfg(feature = "backend-bitmap")]
1717
pub use backend::{ArcSlice, AtomicBitmap, RefSlice};
@@ -113,8 +113,8 @@ impl<B: Bitmap> Bitmap for Option<B> {
113113
pub type BS<'a, B> = <B as WithBitmapSlice<'a>>::S;
114114

115115
/// Helper type alias for referring to the `BitmapSlice` concrete type associated with
116-
/// the memory regions of an object `M: GuestMemory`.
117-
pub type MS<'a, M> = BS<'a, <<M as GuestMemory>::R as GuestMemoryRegion>::B>;
116+
/// the memory regions of an object `M: GuestMemoryBackend`.
117+
pub type MS<'a, M> = BS<'a, <<M as GuestMemoryBackend>::R as GuestMemoryRegion>::B>;
118118

119119
#[cfg(test)]
120120
#[cfg(feature = "backend-bitmap")]
@@ -257,7 +257,7 @@ pub(crate) mod tests {
257257
// Assumptions about M generated by f ...
258258
pub fn test_guest_memory_and_region<M, F>(f: F)
259259
where
260-
M: GuestMemory,
260+
M: GuestMemoryBackend,
261261
F: Fn() -> M,
262262
{
263263
let m = f();

src/bytes.rs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -333,7 +333,7 @@ pub trait Bytes<A> {
333333
/// ```
334334
/// # #[cfg(all(feature = "backend-mmap", feature = "rawfd"))]
335335
/// # {
336-
/// # use vm_memory::{Address, GuestMemory, Bytes, GuestAddress, GuestMemoryMmap};
336+
/// # use vm_memory::{Address, GuestMemoryBackend, Bytes, GuestAddress, GuestMemoryMmap};
337337
/// # use std::fs::File;
338338
/// # use std::path::Path;
339339
/// #

0 commit comments

Comments
 (0)