Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 10 additions & 8 deletions src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -20,14 +20,16 @@ pub enum IoAddress {
}

/// Device IO trait.
/// A device supporting memory based I/O should implement this trait, then
/// register itself against the different IO type ranges it handles.
/// The VMM will then dispatch IO (PIO or MMIO) VM exits by calling into the
/// registered devices read or write method from this trait.
/// A device supporting memory based I/O should implement this trait. For
/// device that has one or several IO (PIO or MMIO) address space, it
/// registers itself against the different IO type ranges it handles with
/// a unique token to distinguish different windows. The VMM will then

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a unique token to distinguish different windows.

If anything, this token should naturally be the base address of that window. And yes, that base address would change when reprogramming PCI BARs, but so would the registration against the MMIO or IO bus. A token is well defined for PCI BARs, but it makes the API less simple and obvious.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may use the base address as the token, but we may also have better choices for token.
For example, PCI bar index may be better than base address because we almost need to map the base address to bar index.
So token gives more flexibility to the driver implementation. And it would be easier to support firecracker by simply ignoring the token argument.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with adding a token with VMM and device specific semantics, is that you have to use your DeviceIo instances with a specific device manager, one that can forward a cookie/token that was passed during device registration time. Your device IO trait becomes semantically bound to your device manager, which I feel is not the cleanest approach.
Adding a base: IoAddress argument would already be useful and help devices.

/// dispatch IO (PIO or MMIO) VM exits by calling into the registered devices
/// read or write method from this trait.
pub trait DeviceIo: Send {
/// Read from the guest physical address `addr` to `data`.
fn read(&mut self, addr: IoAddress, data: &mut [u8]);
/// Read from `offset` of IO address space specified by `token` to `data`.
fn read(&mut self, offset: IoAddress, token: usize, data: &mut [u8]);

/// Write `data` to the guest physical address `addr`.
fn write(&mut self, addr: IoAddress, data: &[u8]);
/// Write `data` to `offset` of IO address space specified by `token`.
fn write(&mut self, offset: IoAddress, token: usize, data: &[u8]);
}