Add device IO trait

[sameo]

No description provided.

[alexandruag]

There's also the option of having one trait for each type of I/O, i.e. PortIoDevice and MmioDevice traits or something along those lines. That seems a bit nicer, especially if there are only going to be two variants in the IoType enum. Also, FWIW, GuestAddresses are a bit jarring to use semantically for port IO.

[jiangliu]

This design may cause some obstacles to the Bus/DeviceManager design, we need to explicitly distinguish between Arc and Arc.

[sameo]

@jiangliu Although I think the Device Manager could be implemented with that approach, it would make for a duplicated API: We'd need to have the same API (register_device, unregister_device, etc) duplicated for each of the variants @alexandruag is proposing. So I think the current proposal is cleaner.

[jiangliu]

To make it clear, I agree with current design with an "io_type: IoType" parameter.

[sameo]

To make it clear, I agree with current design with an "io_type: IoType" parameter.

Yep. And I prefer the io_type approach as well.

[jiangliu]

To address Andreea concern, we may enhance the io_type enum as:
enum IoType {
Pio(u16),
Mmio(GuestAddress),
}

[sameo]

@jiangliu You mean something like that:

/// IO Addresses.
#[derive(Debug, Copy, Clone)]
pub enum IoAddress {
    /// Port I/O address.
    Pio(u16),

    /// Memory mapped I/O address.
    Mmio(GuestAddress),
}

/// 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.
pub trait DeviceIo: Send {
    /// Read from the guest physical address `addr` to `data`.
    fn read(&self, addr: IoAddress, data: &mut [u8]);

    /// Write `data` to the guest physical address `addr`.
    fn write(&self, addr: IoAddress, data: &[u8]);
}

[jiangliu]

exactly:)