Processor allocation receives considerable attention when engineers design a real-time virtualized system. However, an application that interacts with physical equipment also depends on the path between the virtual machine and its I/O devices.

Network adapters, storage controllers, data-acquisition cards, graphics devices, and specialized PCIe hardware can be exposed to a virtual machine in several ways. Each method creates a different balance among compatibility, performance, isolation, hardware sharing, and configuration complexity.

Choosing an I/O strategy therefore requires more than determining whether a device works inside the guest operating system. Engineers must also understand which layers participate in each transfer, where interrupts are handled, whether the device is shared, and how other host activity could affect its behavior

Why I/O Architecture Matters

In a native system, the operating system typically communicates directly with a physical device through its driver. In a virtualized system, additional software layers may participate in that exchange.

Depending on the configuration, an I/O request might pass through:

• The application
• A guest operating-system driver
• A virtual device
• The hypervisor
• A host operating-system driver
• The physical device

Each additional layer performs useful work, such as translating requests, managing shared resources, or maintaining separation among virtual machines. It can also create more opportunities for scheduling delays, resource competition, and variable processing time.

These effects may be acceptable for an operator display or file server but unsuitable for an application that must exchange data with physical equipment within a defined time window.

The goal is not necessarily to eliminate every virtualization layer. It is to choose an I/O path that satisfies the requirements of each device and workload.

Four Common I/O Approaches

The principal options are device emulation, paravirtualized I/O, PCI passthrough, and Single Root I/O Virtualization, commonly called SR-IOV.

I/O approach	Primary advantage	Principal tradeoff
Device emulation	Broad guest compatibility	More software processing in the I/O path
Paravirtualized I/O	Efficient virtual networking and storage	The host remains involved
PCI passthrough	Direct guest control and strong device isolation	The physical device is generally dedicated to one VM
SR-IOV	Direct-style access that can support multiple VMs	Requires compatible hardware, firmware, and drivers

Device Emulation

Device emulation presents the guest with a software representation of familiar hardware. The guest uses a conventional driver, while the virtualization environment translates its requests for the actual device.

Compatibility is the primary benefit. An older guest operating system may already include a driver for the emulated device even if it does not support the host’s current physical hardware.

This can be useful when preserving a legacy software environment. The guest continues to see a device it recognizes while the host manages the newer hardware underneath it.

The tradeoff is that emulation introduces more processing. Device operations must be interpreted and translated before reaching the physical hardware. Host scheduling and shared-resource activity may also affect the I/O path.

Device emulation is generally better suited to:

• Legacy compatibility
• Installation and recovery environments
• Low-volume administrative traffic
• Devices without demanding timing requirements
• Workloads for which convenience matters more than I/O consistency

It should be evaluated carefully before being used for a timing-sensitive data path.

Paravirtualized I/O

Paravirtualized I/O uses drivers designed specifically for virtual environments. Rather than reproducing the behavior of a physical legacy device, the guest and host communicate through a more efficient virtual interface.

Virtio is a common example. It is often used for virtual network adapters, storage devices, consoles, and related services.

Paravirtualized devices generally reduce the processing required by full device emulation. They can provide effective performance for ordinary network and storage workloads while allowing the underlying physical device to remain under host control and potentially serve multiple virtual machines.

However, the host still participates in the I/O path. Packets or storage requests may be processed by host threads, virtual switches, queues, or shared device drivers. These components require CPU time and may compete with other activity.

Paravirtualized I/O can be appropriate for:

• System administration
• General network communication
• File transfers and ordinary storage
• Logging that is not part of a critical control loop
• Devices that must be shared among multiple guests
• Workloads that do not require direct ownership of the hardware

Engineers should identify the host threads and interrupts associated with these virtual devices. CPU shielding for the guest alone may not control activity taking place elsewhere in the I/O path.

PCI Passthrough

PCI passthrough assigns a physical PCIe device directly to a virtual machine. The guest uses the device’s native driver and communicates with it with substantially less host involvement than emulated or paravirtualized I/O.

An Input-Output Memory Management Unit, or IOMMU, helps isolate device memory access so the assigned hardware can operate safely within the guest’s address space.

PCI passthrough offers several advantages for real-time workloads:

• The guest can use the device’s native driver.
• The device is isolated from other virtual machines.
• Fewer host software layers participate in normal I/O.
• Device interrupts can be associated more directly with the guest.
• Specialized PCIe hardware can be assigned to the application that requires it.

The principal limitation is exclusivity. A passed-through physical device is generally dedicated to one virtual machine and unavailable to the host or other guests while assigned.

This can increase the number of adapters required in a consolidated system. If three virtual machines each need direct access to a network interface, the host may need separate physical ports or adapters for them.

PCI passthrough also requires careful hardware planning. Engineers must verify:

• IOMMU support in the processor, chipset, firmware, and virtualization environment
• The device’s IOMMU grouping
• Driver availability in the guest operating system
• Device reset behavior
• Interrupt handling
• NUMA locality
• Whether the device depends on host services or related hardware functions

Some devices contain several functions that cannot be separated cleanly. Others may not reset correctly when a virtual machine restarts. Compatibility should be verified for the specific device and system configuration.

SR-IOV

SR-IOV allows a compatible PCIe device to expose multiple virtual functions. Each virtual function can be assigned to a different virtual machine, giving guests a more direct I/O path while sharing the underlying physical device.

The full device is known as the physical function. It is typically managed by the host. The smaller virtual functions provide portions of the device’s resources to individual guests.

SR-IOV is commonly associated with network adapters, although support exists in other device categories.

Its primary advantage is scalability. Several virtual machines can receive isolated device functions without requiring a separate physical adapter for each guest.

The tradeoffs include:

• Dependence on compatible hardware and firmware
• Guest-driver requirements
• More complex configuration
• Device-specific limits on the number and capabilities of virtual functions
• Continued dependence on the shared physical device
• Possible restrictions on migration, monitoring, or advanced network features

SR-IOV can be useful when several virtual machines need efficient access to a high-capacity device, but it should not be assumed to provide the same behavior as assigning an entire physical device to one guest.

The physical function and its virtual functions still share hardware resources. Engineers should evaluate how activity from one guest could affect the others.

Comparing the Approaches

The correct I/O method depends on the role of the device.

Requirement	Likely starting point
Support an older guest with limited driver availability	Device emulation
Provide ordinary virtual networking or storage	Paravirtualized I/O
Give one real-time VM direct control of specialized hardware	PCI passthrough
Share a compatible high-capacity device among several VMs	SR-IOV
Minimize configuration complexity for noncritical I/O	Paravirtualized I/O
Prevent other VMs from using the assigned device	PCI passthrough

This table is a starting point rather than a final design rule. The device, driver, application, host architecture, and timing requirements must be evaluated together.

Network I/O

A virtualized system may contain several different types of network traffic:

• Timing-sensitive application data
• Control-system communication
• Operator-interface traffic
• Data logging
• File transfers
• Remote administration
• Monitoring and maintenance

These functions do not necessarily need the same type of virtual network interface.

A timing-sensitive application may benefit from a dedicated passed-through network adapter or an appropriate SR-IOV virtual function. Administrative access may work well through a paravirtualized adapter connected to a host-managed virtual network.

When planning network I/O, engineers should consider:

• Whether the interface is dedicated or shared
• Where packet-processing threads run
• Which CPUs handle the device interrupts
• Whether virtual switching is involved
• Whether traffic from other guests can fill shared queues
• Which NUMA node is connected to the adapter
• Whether the application depends on hardware timestamps or other adapter-specific features
• How network load will be reproduced during system testing

Using separate interfaces for critical and noncritical traffic can make resource ownership clearer and simplify troubleshooting.

Storage I/O

Storage is commonly shared among the host and several virtual machines. This makes it convenient, but it can also create contention.

A guest may access a virtual disk backed by:

• A file on the host filesystem
• A logical volume
• A local storage device
• A storage-area network
• A paravirtualized block device
• A passed-through controller or physical disk

For many applications, virtualized storage is appropriate. Operating-system files, development tools, configuration data, and moderate logging workloads may not require direct device ownership.

More care is needed when storage activity is part of a timing-sensitive process. A logging workload can experience delays if it shares a device, controller, queue, or host filesystem with unrelated activity.

Questions to examine include:

• Is storage in the critical execution path?
• Can writes be buffered safely?
• What happens when a queue fills?
• Is the device shared with the host or another VM?
• Are filesystem maintenance tasks running?
• Which CPUs process storage interrupts and host I/O threads?
• Does the application require consistent write completion or only data preservation?

In many systems, the better design is to keep storage out of the critical loop. Timing-sensitive data can be captured in memory and transferred to storage through a controlled process when the application permits it.

Specialized PCIe Devices

Real-time applications often depend on hardware that conventional enterprise virtual environments do not commonly use. Examples include:

• Data-acquisition cards
• FPGA-based I/O
• Analog and digital interfaces
• CAN, MIL-STD-1553, or other communication interfaces
• Timing and synchronization cards
• Motion-control hardware
• Custom PCIe devices

PCI passthrough is often the most practical starting point for these devices because it allows the guest to use the native device driver. Nevertheless, the complete configuration must be evaluated.

The device may use:

• Multiple PCI functions
• Direct memory access
• Message-signaled interrupts
• Large memory regions
• Peer-to-peer communication
• Vendor services
• Custom reset procedures

The guest driver must be compatible with the guest operating system, and the virtualization environment must be able to assign all required device resources.

A card that works in a native system should not automatically be assumed to work when passed through to a virtual machine.

NUMA Locality and Device Placement

PCIe devices are physically connected to a particular processor socket or NUMA node. A virtual machine’s CPU and memory assignments should be considered in relation to that location.

For example, suppose a passed-through data-acquisition card is attached to NUMA node 1 while the VM’s processor cores and memory are allocated from NUMA node 0. Data and interrupt activity may need to cross the system interconnect.

The system may still operate correctly, but its behavior can differ from a configuration in which the processors, memory, and device are local to the same node.

Device installation is therefore part of system configuration moving a card to another slot can change its relationship to the VM’s other resources. See How CPU Shielding, NUMA, and Interrupt Affinity Affect Real-Time Virtual Machines for how to map cores, memory, and interrupts to a NUMA node before assigning a device.

Interrupt Handling

Every I/O method has an interrupt path.

With emulated or paravirtualized devices, a physical interrupt may first be handled by the host. The host then performs additional processing before the guest receives a virtual interrupt.

With a passed-through device, the path is more direct, but interrupt routing and processor assignment still need to be configured and observed.

An idle device may generate little activity during initial testing, even though its effect can change considerably under representative data rates. See How CPU Shielding, NUMA, and Interrupt Affinity Affect Real-Time Virtual Machines for how to determine which interrupts belong to each device, which CPUs should handle them, and how to keep automatic balancing services from changing that assignment later.

A Mixed I/O Architecture Is Often the Best Choice

A real-time virtual machine rarely needs direct hardware access for every function.

A practical design might use:

• PCI passthrough for specialized acquisition or control hardware
• A passed-through or SR-IOV network interface for timing-sensitive communication
• Paravirtualized networking for administration
• Paravirtualized storage for the guest operating system
• A separate logging path for noncritical data
• Emulation only where legacy compatibility requires it

This approach reserves the most direct methods for I/O that materially affects application behavior. Less critical functions can use shared virtual resources, reducing hardware requirements and simplifying administration.

The boundaries should be based on measured requirements rather than applying the same method everywhere.

A Practical Evaluation Process

1. Inventory the Devices

List every device the virtual machine must use, including network, storage, graphics, timing, and specialized interfaces.

2. Classify Each I/O Path

Identify whether each device is part of a critical control loop, supports a timing-sensitive function, or serves a general-purpose role.

3. Confirm Guest Support

Verify that the guest operating system contains a suitable driver for the proposed virtual or physical device.

4. Map the Hardware

Document PCIe slots, IOMMU groups, NUMA nodes, interrupt assignments, and relationships among devices, processors, and memory.

5. Select an Access Method

Choose emulation, paravirtualized I/O, passthrough, or SR-IOV based on the requirements of each device.

6. Allocate Host Resources

Reserve sufficient processors and memory for host-side I/O work. Do not place all available resources inside the guest.

7. Configure Interrupts and Supporting Threads

Identify both device interrupts and any host threads involved in processing the I/O path.

8. Test Under Representative Load

Exercise CPU, network, storage, and device activity simultaneously. Include realistic data rates, background traffic, logging, and competing VM workloads.

9. Test Failure and Restart Behavior

Determine what happens when the guest restarts, the host reboots, a cable is disconnected, or a device reports an error. Confirm that passed-through hardware returns to a usable state.

10. Document the Configuration

Record device models, firmware, PCIe locations, guest drivers, IOMMU assignments, interrupt affinity, NUMA placement, and virtual-machine settings.

Choosing the Appropriate I/O Path

No single I/O method is correct for every real-time virtual machine.

Device emulation offers compatibility, particularly for legacy guests, but introduces more software processing. Paravirtualized I/O is efficient for ordinary virtual networking and storage, although it continues to depend on host resources. PCI passthrough gives one guest more direct and isolated access to a physical device. SR-IOV can extend direct-style access to several guests when the device supports it.

The decision should begin with the function of the device and the application’s measured requirements. Engineers should then examine the full path from the guest application to the physical hardware, including drivers, host processes, interrupts, memory placement, and shared resources.

RedHawk KVM-RT supports virtualized system configurations in which processor, memory, interrupt, and I/O resources are deliberately assigned. The selected architecture still needs to be validated with the actual devices, drivers, workloads, and hardware that will be used in operation.

Frequently Asked Questions:

Is PCI passthrough always the best choice for a real-time virtual machine?

No. PCI passthrough can provide direct access and strong isolation, but it dedicates the device to one VM and adds hardware and configuration requirements. General-purpose networking and storage may be better served by paravirtualized devices.

Can multiple virtual machines share a passed-through PCIe device?

A physical device assigned through standard PCI passthrough is generally dedicated to one VM. A device that supports SR-IOV may expose multiple virtual functions that can be assigned separately.

What is the difference between Virtio and device emulation?

Device emulation reproduces the behavior of familiar hardware so an existing guest driver can use it. Virtio uses virtualization-aware guest drivers to communicate more efficiently with the host.

Does PCI passthrough remove all virtualization overhead?

It removes several host-managed layers from the normal I/O path, but the application still runs in a virtualized system. Guest scheduling, interrupt routing, memory placement, device behavior, and overall resource allocation still affect the configuration.

How should engineers test virtualized I/O?

Test the complete system with representative data rates and competing CPU, memory, network, storage, and VM activity. Include startup, restart, error recovery, and sustained-load conditions, not only an idle benchmark.