Difference between revisions of "LIME Is Mediated Emulation"

From Open-IOV
Jump to navigation Jump to search
Line 20: Line 20:


=== Win64 Orchestration ===
=== Win64 Orchestration ===
Because LIME necessarily provisions application data, program files, and [https://openmdev.io/index.php/Glossary#NUMA_Node 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 '[https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-tools.md#using-windows-appvms-in-seamless-mode seamless-mode]' execution of guest programs similar to that of [https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-tools.md QubesOS] with hardware GPU acceleration added.
Because LIME necessarily provisions application data, program files, and [https://openmdev.io/index.php/Glossary#NUMA_Node 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 '[https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-tools.md#using-windows-appvms-in-seamless-mode seamless-mode]' execution of guest programs similar to that of [https://www.qubes-os.org/doc/ QubesOS] with hardware GPU acceleration added.


=== Compatibility With Other ABIs ===
=== Compatibility With Other ABIs ===

Revision as of 13:21, 23 August 2022

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, 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 seamless execution of any ABI with near indistinguishable performance compared to native execution.

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 issue 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).