LIME Is Mediated Emulation

From Open-IOV
Jump to navigation Jump to search

LIME Is Mediated Emulation is an in-development feature in LibVF.IO which enables the execution of full performance Win64 binaries with full compatibility for all current and future software making use of the Windows ABI. An initial demo of this technology can be viewed here.

Design Goals

LIME aims to provide similar functionality to WINE Is Not Emulation, Valve's Proton / DXVK but with the use of graphics virtualization (vGPU/SR-IOV on consumer GPUs), a shared filesystem between host/guest, and KVM Frame Relay (high performance graphics buffer sharing via Inter-VM Shared Memory Device / IVSHMEM).

Compared to WINE, and Proton the benefits of this approach are that Win64 binaries execute without the incompatibilities introduced in new games taking advantage of the latest version of DirectX, or when changes are introduced to the latest version of the Win64 ABI.

This functionality is enabled via the use of GPU Virtual Machine (for consumer GPU Virtualization), VirtIO-FS (for host <-> guest filesystem sharing), Looking Glass (for host <-> guest shared frame buffer), and LibVF.IO (for orchestration).

Use-Cases

Win64 Subsystem

LIME's most immediate use case is around ABI compatibility with Win64 programs in environments without native support.

A blog post detailing the problems which lead to this work can be read here. A summary of this post is traditional models for backwards compatibility with Application Binary Interfaces (ABIs) lock-in existing models for kernel/userland development and stagnate architectural innovation. On the other hand consumer oriented systems like those based on Darwin/XNU break backwards compatibility with user programs version to version of the system in order to introduce architectural improvements in the kernel / userland (for instance micro-service device drivers which may recover from faults at OS runtime).

These two approaches might be considered two discretely separable models for software development 'enterprise' /'consumer' - LIME might then be considered a third approach which preserves the functions of both prior approaches (continual innovation afforded in the kernel-space and backwards compatibility with existing software libraries).

ie: A method by which programs "import" a particular explicitly versioned ABI similar to how Docker provisions chroot resources like configuration files and support libraries, but extended to drivers, and the kernel.

Win64 Orchestration

Because LIME necessarily provisions application data, program files, and NUMA-aware vCPU/vGPU resources (in the context of multi-GPU, multi-socket CPU systems) through LibVF.IO for automatic execution by one or more VM guests LIME might provide an ideal architecture for orchestration of Win64 applications at scale. This could include execution of programs for game streaming in a server environment, or multiple applications in a single user environment for 'seamless-mode' execution of guest programs similar to that of QubesOS with hardware GPU acceleration added.

Compatibility With Other ABIs

To solve the problems of 'ABI lock-in' discussed in the "Why Computers Suck" post it may be possible to port LIME support to multiple different guest operating systems allowing execution of any program with any ABI with near indistinguishable performance compared to native execution.

Quality of Service (QoS)

VFIO-Mdev functionality like that used in GPU Virtual Machine (GVM) provides granular GPU resource allocation and load balancing functions similar to those seen in control groups (cgroups) as they are commonly applied today to RAM and CPU resources. In the context LIME VFIO-Mdev could be applied for load balancing of individual processes running in a virtualized state to ensure individual processes making use of the GPU cannot deny service to others on the system.

Development Status

Development of this functionality is ongoing. Efforts to improve LIME are primarily focused on stabilization of shared filesystem functions.

VirtIO-FS

VirtIO-FS provides shared filesystem functionality between host and guest using FUSE which is ideal for LIME, however in the context of Windows guests the C version of virtiofsd appears unstable (seen in virtio-win issue 550 [closed], 723 [closed], 724 [open]). Testing has been performed by members of the OpenMdev community which have shown initial signs of increased filesystem stability under continuous read/write loads using the Rust version of virtiofsd (virtiofsd-rs).

While many programs can be stored in the VirtIO-FS shared directory some programs such as Steam don't want to install programs into the VirtIO-FS drive (seen as a secondary drive in Windows - in LibVF.IO often as disk D:/ if no additional media is attached). This game installation behaviour (which drive the user may place their programs in) may not be in common with other game stores such as the Epic Games Store, or Good Old Games (GOG).