FriendOS Wiki - User contributions [en]

Main Page

2024-12-18T14:03:24Z

Repnop: Remove old invite link from Helpful Links section

== Welcome to the FriendOS Wiki! ==

The FriendOS Wiki is a community-driven wiki for the [https://discord.gg/U9feA9z669 FriendOS Discord server]. This wiki, as well as the Discord server, are intended to create a more inclusive, supportive, and welcoming environment for people learning about operating systems development, which historically is not very common. The purpose of this wiki is to provide resources for newbies and veterans alike, as well as allowing contributions from the community members so that people can easily create & share information about the concepts that they frequently work with. If you think you have something to contribute, make an account and start writing! If you have comments or questions, you can discuss the wiki in the #wiki channel on the Discord server.

== Helpful Links ==

* [[Special:AllPages|See all pages]]
* [[:Category:Architectures|Architectures Index]]

PLIC

2023-02-03T02:29:24Z

Repnop:

The Platform Interrupt Controller (PLIC) is the standardized device for receiving, routing, and completing [[Interrupts#External|external interrupts]] with configuration per-[[hart]] and per-[[Privilege Mode|privilege mode]]. Originally, the PLIC design is based on early SiFive designs which were then slightly refined and standardized and only supports basic interrupt enabling/disabling, prioritization and routing. As part of the [[RISC-V Advanced Interrupt Architecture]] (AIA), the original PLIC design is extended to support more types of interrupts, namely [[Message Signaled Interrupt]]<nowiki/>s (MSIs), which are important for technologies like [[PCI]]. The PLIC specification can be found at https://github.com/riscv/riscv-plic-spec while the APLIC specification is available at https://github.com/riscv/riscv-aia.

== Original PLIC Design ==
The original PLIC design consist of a set of: interrupt source priorities, interrupt pending bits, per-context interrupt enable bits, and then per-context priority threshold & claim/complete regions. A context is the combination of a hart ID and a privilege mode, though the specific ordering of contexts is platform-specific and cannot be generalized between them. A small table below has been added for quick reference, but likely will not contain a formula for calculating the context for every platform. The memory layout for the PLIC is as follows (taken from the PLIC spec):
base + 0x000000: Reserved (interrupt source 0 does not exist)
base + 0x000004: Interrupt source 1 priority
base + 0x000008: Interrupt source 2 priority
...
base + 0x000FFC: Interrupt source 1023 priority
base + 0x001000: Interrupt Pending bit 0-31
base + 0x00107C: Interrupt Pending bit 992-1023
...
base + 0x002000: Enable bits for sources 0-31 on context 0
base + 0x002004: Enable bits for sources 32-63 on context 0
...
base + 0x00207C: Enable bits for sources 992-1023 on context 0
base + 0x002080: Enable bits for sources 0-31 on context 1
base + 0x002084: Enable bits for sources 32-63 on context 1
...
base + 0x0020FC: Enable bits for sources 992-1023 on context 1
base + 0x002100: Enable bits for sources 0-31 on context 2
base + 0x002104: Enable bits for sources 32-63 on context 2
...
base + 0x00217C: Enable bits for sources 992-1023 on context 2
...
base + 0x1F1F80: Enable bits for sources 0-31 on context 15871
base + 0x1F1F84: Enable bits for sources 32-63 on context 15871
base + 0x1F1FFC: Enable bits for sources 992-1023 on context 15871
...
base + 0x1FFFFC: Reserved
base + 0x200000: Priority threshold for context 0
base + 0x200004: Claim/complete for context 0
base + 0x200008: Reserved
...
base + 0x200FFC: Reserved
base + 0x201000: Priority threshold for context 1
base + 0x201004: Claim/complete for context 1
...
base + 0x3FFF000: Priority threshold for context 15871
base + 0x3FFF004: Claim/complete for context 15871
base + 0x3FFF008: Reserved
...
base + 0x3FFFFFC: Reserved

Or, more usefully:

<syntaxhighlight lang="rust" line>
#[repr(C)]
struct Plic {
source_priorities: [u32; 1024],
interrupt_pending: [u32; 32],
_padding1: [u8; 3968],
interrupt_enable: [[u32; 32]; 15872],
_padding2: [u8; 57344],
threshold_and_claim: [[u32; 1024]; 15872],
}
</syntaxhighlight>

Each <code>u32</code> inside of the <code>source_priorities</code> is a priority level from <code>0..=7</code> (on most platforms, see your platform specification for more complete information) of increasing priority level where priority <code>0</code> is considered "never interrupt" and will cause the interrupt to effectively be disabled, with the exception of interrupt #0, which does not exist and is reserved. <code>interrupt_pending</code> is a read-only bitmap of the pending status for priorities <code>1..=1024</code> (with the interrupt #0 bit hardwired to zero). Both <code>interrupt_enable</code> and <code>threshold_and_claim</code> work on the aforementioned contexts, and need to be indexed at a platform-specific index for a given hart and privilege mode combination. The <code>interrupt_enable</code> consists of another bitmap of interrupt sources (again with interrupt #0 for each context being hardwired to zero) which allow enabling and disabling specific interrupt sources at the context level, but also means that if you wish for a given interrupt to trigger across any hart, it will need to be enabled for each context for the privilege mode you are executing in. <code>threshold_and_claim</code> is made up of a threshold <code>u32</code> value and a claim <code>u32</code> value, with the rest of the <code>u32</code>s being reserved and should not be written to.

=== Hart & Privilege Context Mappings ===
{| class="wikitable"
|+
!Platform
!M-mode Context
!S-mode Context
|-
|QEMU virt
|<code>hart_id * 2</code>
|
hart_id * 2 + 1
|-
|QEMU sifive_u†
|Monitor hart: <code>0</code>

Other harts: <code>hart_id * 2 + 1</code>
|<code>hart_id * 2</code>
|}
†This platform contains a [[Monitor Hart]] which does not support S-mode and does not have the same extension availability as the general-purpose harts

=== Setting Interrupt Source Priorities & Thresholds ===
TODO

=== Enabling and Disabling Interrupts ===
To enable or disable any given interrupt source, simply toggle the specific bit that corresponds to the interrupt source in the <code>interrupt_enable</code> for the context for which you wish to enable or disable the interrupt. Example Rust code:<syntaxhighlight lang="rust" line="1">
unsafe fn enable_interrupt(plic: *mut Plic, context: usize, interrupt_source: usize) {
// Sanity checks, neither values would be valid
if context >= 15872 || interrupt_source >= 1024 {
return;
}

// Calculate the bit-group index and the bit index for that bit-group
let (u32_index, bit) = (interrupt_source / 32, interrupt_source % 32);

// Calculate the address of the bit-group
let bit_group_ptr = unsafe { core::ptr::addr_of_mut!((*plic).interrupt_enable[context][u32_index]) };

// Read the current value
let previous = unsafe { bit_group_ptr.read_volatile() };

// Set the bit for the interrupt source
let new = previous | (1 << bit);

// Write the new value
unsafe { bit_group_ptr.write_volatile(new) };
}

unsafe fn disable_interrupt(plic: *mut Plic, context: usize, interrupt_source: usize) {
// Sanity checks, neither values would be valid
if context >= 15872 || interrupt_source >= 1024 {
return;
}

// Calculate the bit-group index and the bit index for that bit-group
let (u32_index, bit) = (interrupt_source / 32, interrupt_source % 32);

// Calculate the address of the bit-group
let bit_group_ptr = unsafe { core::ptr::addr_of_mut!((*plic).interrupt_enable[context][u32_index]) };

// Read the current value
let previous = unsafe { bit_group_ptr.read_volatile() };

// Clear the bit for the interrupt source
let new = previous & !(1 << bit);

// Write the new value
unsafe { bit_group_ptr.write_volatile(new) };
}
</syntaxhighlight>

=== Acknowledging Interrupts — Claim/Complete Mechanism ===
TODO
__FORCETOC__

PLIC

2023-02-03T02:15:21Z

Repnop:

The Platform Interrupt Controller (PLIC) is the standardized device for receiving, routing, and completing [[Interrupts#External|external interrupts]] with configuration per-[[hart]] and per-[[Privilege Mode|privilege mode]]. Originally, the PLIC design is based on early SiFive designs which were then slightly refined and standardized and only supports basic interrupt enabling/disabling, prioritization and routing. As part of the [[RISC-V Advanced Interrupt Architecture]] (AIA), the original PLIC design is extended to support more types of interrupts, namely [[Message Signaled Interrupt]]<nowiki/>s (MSIs), which are important for technologies like [[PCI]]. The PLIC specification can be found at https://github.com/riscv/riscv-plic-spec while the APLIC specification is available at https://github.com/riscv/riscv-aia.

== Original PLIC Design ==
The original PLIC design consist of a set of: interrupt source priorities, interrupt pending bits, per-context interrupt enable bits, and then per-context priority threshold & claim/complete regions. A context is the combination of a hart ID and a privilege mode, though the specific ordering of contexts is platform-specific and cannot be generalized between them. A small table below has been added for quick reference, but likely will not contain a formula for calculating the context for every platform. The memory layout for the PLIC is as follows (taken from the PLIC spec):
base + 0x000000: Reserved (interrupt source 0 does not exist)
base + 0x000004: Interrupt source 1 priority
base + 0x000008: Interrupt source 2 priority
...
base + 0x000FFC: Interrupt source 1023 priority
base + 0x001000: Interrupt Pending bit 0-31
base + 0x00107C: Interrupt Pending bit 992-1023
...
base + 0x002000: Enable bits for sources 0-31 on context 0
base + 0x002004: Enable bits for sources 32-63 on context 0
...
base + 0x00207C: Enable bits for sources 992-1023 on context 0
base + 0x002080: Enable bits for sources 0-31 on context 1
base + 0x002084: Enable bits for sources 32-63 on context 1
...
base + 0x0020FC: Enable bits for sources 992-1023 on context 1
base + 0x002100: Enable bits for sources 0-31 on context 2
base + 0x002104: Enable bits for sources 32-63 on context 2
...
base + 0x00217C: Enable bits for sources 992-1023 on context 2
...
base + 0x1F1F80: Enable bits for sources 0-31 on context 15871
base + 0x1F1F84: Enable bits for sources 32-63 on context 15871
base + 0x1F1FFC: Enable bits for sources 992-1023 on context 15871
...
base + 0x1FFFFC: Reserved
base + 0x200000: Priority threshold for context 0
base + 0x200004: Claim/complete for context 0
base + 0x200008: Reserved
...
base + 0x200FFC: Reserved
base + 0x201000: Priority threshold for context 1
base + 0x201004: Claim/complete for context 1
...
base + 0x3FFF000: Priority threshold for context 15871
base + 0x3FFF004: Claim/complete for context 15871
base + 0x3FFF008: Reserved
...
base + 0x3FFFFFC: Reserved

Or, more usefully:

<syntaxhighlight lang="rust" line>
#[repr(C)]
struct Plic {
source_priorities: [u32; 1024],
interrupt_pending: [u32; 32],
_padding1: [u8; 3968],
interrupt_enable: [[u32; 32]; 15872],
_padding2: [u8; 57344],
threshold_and_claim: [[u32; 1024]; 15872],
}
</syntaxhighlight>

Each <code>u32</code> inside of the <code>source_priorities</code> is a priority level from <code>0..=7</code> (on most platforms, see your platform specification for more complete information) of increasing priority level where priority <code>0</code> is considered "never interrupt" and will cause the interrupt to effectively be disabled, with the exception of interrupt #0, which does not exist and is reserved. <code>interrupt_pending</code> is a read-only bitmap of the pending status for priorities <code>1..=1024</code> (with the interrupt #0 bit hardwired to zero). Both <code>interrupt_enable</code> and <code>threshold_and_claim</code> work on the aforementioned contexts, and need to be indexed at a platform-specific index for a given hart and privilege mode combination. The <code>interrupt_enable</code> consists of another bitmap of interrupt sources (again with interrupt #0 for each context being hardwired to zero) which allow enabling and disabling specific interrupt sources at the context level, but also means that if you wish for a given interrupt to trigger across any hart, it will need to be enabled for each context for the privilege mode you are executing in. <code>threshold_and_claim</code> is made up of a threshold <code>u32</code> value and a claim <code>u32</code> value, with the rest of the <code>u32</code>s being reserved and should not be written to.

=== Hart & Privilege Context Mappings ===
{| class="wikitable"
|+
!Platform
!M-mode Context
!S-mode Context
|-
|QEMU virt
|<code>hart_id * 2</code>
|
hart_id * 2 + 1
|-
|QEMU sifive_u†
|Monitor hart: <code>0</code>

Other harts: <code>hart_id * 2 + 1</code>
|<code>hart_id * 2</code>
|}
†This platform contains a [[Monitor Hart]] which does not support S-mode and does not have the same extension availability as the general-purpose harts

=== Enabling and Disabling Interrupts ===
To enable or disable any given interrupt source, simply toggle the specific bit that corresponds to the interrupt source in the <code>interrupt_enable</code> for the context for which you wish to enable or disable the interrupt. Example Rust code:<syntaxhighlight lang="rust" line="1">
unsafe fn enable_interrupt(plic: *mut Plic, context: usize, interrupt_source: usize) {
// Sanity checks, neither values would be valid
if context >= 15872 || interrupt_source >= 1024 {
return;
}

// Calculate the bit-group index and the bit index for that bit-group
let (u32_index, bit) = (interrupt_source / 32, interrupt_source % 32);

// Calculate the address of the bit-group
let bit_group_ptr = unsafe { core::ptr::addr_of_mut!((*plic).interrupt_enable[context][u32_index]) };

// Read the current value
let previous = unsafe { bit_group_ptr.read_volatile() };

// Set the bit for the interrupt source
let new = previous | (1 << bit);

// Write the new value
unsafe { bit_group_ptr.write_volatile(new) };
}

unsafe fn disable_interrupt(plic: *mut Plic, context: usize, interrupt_source: usize) {
// Sanity checks, neither values would be valid
if context >= 15872 || interrupt_source >= 1024 {
return;
}

// Calculate the bit-group index and the bit index for that bit-group
let (u32_index, bit) = (interrupt_source / 32, interrupt_source % 32);

// Calculate the address of the bit-group
let bit_group_ptr = unsafe { core::ptr::addr_of_mut!((*plic).interrupt_enable[context][u32_index]) };

// Read the current value
let previous = unsafe { bit_group_ptr.read_volatile() };

// Clear the bit for the interrupt source
let new = previous & !(1 << bit);

// Write the new value
unsafe { bit_group_ptr.write_volatile(new) };
}
</syntaxhighlight>
__FORCETOC__

PLIC

2023-02-03T02:13:41Z

Repnop:

The Platform Interrupt Controller (PLIC) is the standardized device for receiving, routing, and completing [[Interrupts#External|external interrupts]] with configuration per-[[hart]] and per-[[Privilege Mode|privilege mode]]. Originally, the PLIC design is based on early SiFive designs which were then slightly refined and standardized and only supports basic interrupt enabling/disabling, prioritization and routing. As part of the [[RISC-V Advanced Interrupt Architecture]] (AIA), the original PLIC design is extended to support more types of interrupts, namely [[Message Signaled Interrupt]]<nowiki/>s (MSIs), which are important for technologies like [[PCI]]. The PLIC specification can be found at https://github.com/riscv/riscv-plic-spec while the APLIC specification is available at https://github.com/riscv/riscv-aia.

== Original PLIC Design ==
The original PLIC design consist of a set of: interrupt source priorities, interrupt pending bits, per-context interrupt enable bits, and then per-context priority threshold & claim/complete regions. A context is the combination of a hart ID and a privilege mode, though the specific ordering of contexts is platform-specific and cannot be generalized between them. A small table below has been added for quick reference, but likely will not contain a formula for calculating the context for every platform. The memory layout for the PLIC is as follows (taken from the PLIC spec):
base + 0x000000: Reserved (interrupt source 0 does not exist)
base + 0x000004: Interrupt source 1 priority
base + 0x000008: Interrupt source 2 priority
...
base + 0x000FFC: Interrupt source 1023 priority
base + 0x001000: Interrupt Pending bit 0-31
base + 0x00107C: Interrupt Pending bit 992-1023
...
base + 0x002000: Enable bits for sources 0-31 on context 0
base + 0x002004: Enable bits for sources 32-63 on context 0
...
base + 0x00207C: Enable bits for sources 992-1023 on context 0
base + 0x002080: Enable bits for sources 0-31 on context 1
base + 0x002084: Enable bits for sources 32-63 on context 1
...
base + 0x0020FC: Enable bits for sources 992-1023 on context 1
base + 0x002100: Enable bits for sources 0-31 on context 2
base + 0x002104: Enable bits for sources 32-63 on context 2
...
base + 0x00217C: Enable bits for sources 992-1023 on context 2
...
base + 0x1F1F80: Enable bits for sources 0-31 on context 15871
base + 0x1F1F84: Enable bits for sources 32-63 on context 15871
base + 0x1F1FFC: Enable bits for sources 992-1023 on context 15871
...
base + 0x1FFFFC: Reserved
base + 0x200000: Priority threshold for context 0
base + 0x200004: Claim/complete for context 0
base + 0x200008: Reserved
...
base + 0x200FFC: Reserved
base + 0x201000: Priority threshold for context 1
base + 0x201004: Claim/complete for context 1
...
base + 0x3FFF000: Priority threshold for context 15871
base + 0x3FFF004: Claim/complete for context 15871
base + 0x3FFF008: Reserved
...
base + 0x3FFFFFC: Reserved

Or, more usefully:

<syntaxhighlight lang="rust" line>
#[repr(C)]
struct Plic {
source_priorities: [u32; 1024],
interrupt_pending: [u32; 32],
_padding1: [u8; 3968],
interrupt_enable: [[u32; 32]; 15872],
_padding2: [u8; 57344],
threshold_and_claim: [[u32; 1024]; 15872],
}
</syntaxhighlight>

Each <code>u32</code> inside of the <code>source_priorities</code> is a priority level from <code>0..=7</code> (on most platforms, see your platform specification for more complete information) of increasing priority level where priority <code>0</code> is considered "never interrupt" and will cause the interrupt to effectively be disabled, with the exception of interrupt #0, which does not exist and is reserved. <code>interrupt_pending</code> is a read-only bitmap of the pending status for priorities <code>1..=1024</code> (with the interrupt #0 bit hardwired to zero). Both <code>interrupt_enable</code> and <code>threshold_and_claim</code> work on the aforementioned contexts, and need to be indexed at a platform-specific index for a given hart and privilege mode combination. The <code>interrupt_enable</code> consists of another bitmap of interrupt sources (again with interrupt #0 for each context being hardwired to zero) which allow enabling and disabling specific interrupt sources at the context level, but also means that if you wish for a given interrupt to trigger across any hart, it will need to be enabled for each context for the privilege mode you are executing in. <code>threshold_and_claim</code> is made up of a threshold <code>u32</code> value and a claim <code>u32</code> value, with the rest of the <code>u32</code>s being reserved and should not be written to.

=== Hart & Privilege Context Mappings ===
{| class="wikitable"
|+
!Platform
!M-mode Context
!S-mode Context
|-
|QEMU virt
|<code>hart_id * 2</code>
|
hart_id * 2 + 1
|-
|QEMU sifive_u†
|Monitor hart: <code>0</code>

Other harts: <code>hart_id * 2 + 1</code>
|<code>hart_id * 2</code>
|}
†This platform contains a [[Monitor Hart]] which does not support S-mode and does not have the same extension availability as the general-purpose harts

=== Enabling and Disabling Interrupts ===
To enable or disable any given interrupt source, simply toggle the specific bit that corresponds to the interrupt source in the <code>interrupt_enable</code> for the context for which you wish to enable or disable the interrupt. Example Rust code:<syntaxhighlight lang="rust" line="1">
unsafe fn enable_interrupt(plic: *mut Plic, context: usize, interrupt_source: usize) {
// Sanity checks, neither values would be valid
if context >= 15872 || interrupt_source >= 1024 {
return;
}

// Calculate the bit-group index and the bit index for that bit-group
let (u32_index, bit) = (interrupt_source / 32, interrupt_source % 32);

// Calculate the address of the bit-group
let bit_group_ptr = unsafe { core::ptr::addr_of_mut!((*plic).interrupt_enable[context][u32_index]) };

// Read the current value
let previous = unsafe { bit_group_ptr.read_volatile() };

// Set the bit for the interrupt source
let new = previous | (1 << bit);

// Write the new value
unsafe { bit_group_ptr.write_volatile(new) };
}

unsafe fn disable_interrupt(plic: *mut Plic, context: usize, interrupt_source: usize) {
// Sanity checks, neither values would be valid
if context >= 15872 || interrupt_source >= 1024 {
return;
}

// Calculate the bit-group index and the bit index for that bit-group
let (u32_index, bit) = (interrupt_source / 32, interrupt_source % 32);

// Calculate the address of the bit-group
let bit_group_ptr = unsafe { core::ptr::addr_of_mut!((*plic).interrupt_enable[context][u32_index]) };

// Read the current value
let previous = unsafe { bit_group_ptr.read_volatile() };

// Set the bit for the interrupt source
let new = previous & !(1 << bit);

// Write the new value
unsafe { bit_group_ptr.write_volatile(new) };
}
</syntaxhighlight>
__FORCETOC__

PLIC

2023-02-02T02:45:36Z

Repnop:

PLIC

2023-02-02T02:44:13Z

Repnop:

PLIC

2023-02-02T01:54:49Z

Repnop: Initial writeup -- incomplete but need to restart

Main Page

2022-11-24T02:22:59Z

Repnop:

== Welcome to the FriendOS Wiki! ==

The FriendOS Wiki is a community-driven wiki for the [https://discord.gg/U9feA9z669 FriendOS Discord server]. This wiki, as well as the Discord server, are intended to create a more inclusive, supportive, and welcoming environment for people learning about operating systems development, which historically is not very common. The purpose of this wiki is to provide resources for newbies and veterans alike, as well as allowing contributions from the community members so that people can easily create & share information about the concepts that they frequently work with. If you think you have something to contribute, make an account and start writing! If you have comments or questions, you can discuss the wiki in the #wiki channel on the Discord server.

== Helpful Links ==

* [https://discord.gg/U9feA9z669 Discord invite link]
* [[Special:AllPages|See all pages]]

Main Page

2022-11-24T02:18:32Z

Repnop: Add a bit more context

== Welcome to the FriendOS Wiki! ==

The FriendOS Wiki is a community-driven wiki for the [https://discord.gg/U9feA9z669 FriendOS Discord server]. This wiki, as well as the Discord server, are intended to create a more inclusive, supportive, and welcoming environment for people learning about operating systems development, which historically is not very common. The purpose of this wiki is to provide resources for newbies and veterans alike, as well as allowing contributions from the community members so that people can easily create & share information about the concepts that they frequently work with.

== Helpful Links ==

* [https://discord.gg/U9feA9z669 Discord invite link]
* [[Special:AllPages|See all pages]]

VirtIO

2022-11-22T23:02:44Z

Repnop:

VirtIO is a standard for performant virtualized hardware for use within virtual machines, created and managed by the [https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio OASIS Open Virtual I/O Device TC]. VirtIO supports a variety of devices, such as, but not limited to: block (e.g. hard drive), network card, GPU, etc. Each of these devices have their own specific configuration and features, but all use the same underlying VirtIO queue structure for relaying data and commands to & from the device.

=== Device Types ===
{| class="wikitable sortable mw-collapsible"
|+VirtIO Device Types
!Device Name
!Device ID
!Description
|-
|Network Card
|1
|Ethernet network interface
|-
|Block Device
|2
|Block storage capabilities, e.g. hard drive, for storing files and other information
|-
|Console
|3
|Serial console device for simple I/O communication
|-
|Entropy Source
|4
|A source of entropy for cryptographically secure [[PRNG]]<nowiki/>s
|-
|Memory Ballooning (Traditional)
|5
|[TODO]
|-
|ioMemory
|6
|[TODO]
|-
|rpmsg
|7
|[TODO]
|-
|SCSI Host
|8
|Grouping of one or more virtual logical units (e.g. disks) that can be managed via the SCSI protocol
|-
|9P Transport
|9
|[TODO]
|-
|MAC80211 WLAN
|10
|802.11 WLAN interface for wireless [[LAN]] communication
|-
|rproc Serial
|11
|[TODO]
|-
|VirtIO CAIF
|12
|[TODO]
|-
|Memory Balloon
|13
|[TODO]
|-
|GPU
|16
|2D & 3D GPU device, requires a 3D GPU on the host machine for 3D mode, as well as negotiating specific features
|-
|
|
|
|-
|
|
|
|-
|
|
|
|}

=== Device Transports ===
VirtIO supports three different types of device transports: [[PCI|PCI Bus]], [[MMIO]], and [[Channel I/O]]. The PCIe transport is configured via the normal PCIe configuration mechanisms, while the MMIO transport is configured strictly via MMIO reads and writes.

File:Friendos-wikiicon.png

2022-11-22T22:13:55Z

Repnop:

File:Friendos.png

2022-11-22T22:11:03Z

Repnop:

VirtIO

2022-11-22T21:54:06Z

Repnop: Initial page test

VirtIO is a standard for performant virtualized hardware for use within virtual machines created and managed by the [https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio OASIS Open Virtual I/O Device TC].