Various clean-ups, additions
Refactoring of the home page. Adding a page for virtual machine monitors.
This commit is contained in:
lukas
@ -8,15 +8,17 @@ editor: markdown
|
||||
dateCreated: 2022-01-12T14:25:25.960Z
|
||||
---
|
||||
|
||||
# Guest operating system
|
||||
# Guest operating systems support
|
||||
|
||||
> Phyllome OS 🤎 other operating systems. It is meant to be a cozy platform for almost any modern operating systems to thrive.
|
||||
|
||||
Although Phyllome OS would like to support as many operating systems as possible, it mainly focuses on modern, UEFI-compatible operating systems that are shipping with at least some support for `virtio` devices.
|
||||
Although Phyllome OS would like to support as many operating systems as possible, it mainly focuses on modern, UEFI-compatible operating systems that are shipping with at least some support for [virtio devices](/virt/lexicon#paravirtualization).
|
||||
|
||||
## Category of operating systems
|
||||
|
||||
As of today, without accounting for Linux distributions, there are dozens of production-ready operating systems. There are two families of operating systems that dominate this space, the Unix family and the Windows family. Everything else will be categorized as independent.
|
||||
As of today, without accounting for Linux distributions, there are dozens of production-ready operating systems.
|
||||
|
||||
That being said, there are two families of operating systems that dominate this space, the Unix family and the Windows family. Everything else will be categorized as independent.
|
||||
|
||||
### UNIX-family
|
||||
|
||||
@ -49,17 +51,17 @@ When it comes to its longevity and number of variants, the UNIX family is by far
|
||||
|
||||
| | Linux | Darwin | Windows |
|
||||
| :- | :-: | :-: | :-: |
|
||||
| *Chipset* | `i440fx` `Q35` `virt` | `Q35` | `i440fx` `Q35` `virt` |
|
||||
| *Platform firmware* | [`SeaBIOS`](/virt/vm/firmware#seabios) [`OVMF`](/virt/vm/firmware#ovmf) [`RHF`](/virt/vm/firmware#rust-hypervisor-firmware) [^1] | [`OVMF`](/virt/vm/firmware#ovmf) | [`SeaBIOS`](/virt/vm/firmware#seabios) [`OVMF`](/virt/vm/firmware#ovmf) [`RHF`](/virt/vm/firmware#rust-hypervisor-firmware) |
|
||||
| *`virtio-gpu`* | **Yes** | No | No |
|
||||
| *`virtio-video`* | *Upcoming* | No | No |
|
||||
| *`virtio-snd`* | *Upcoming* | No | No |
|
||||
| *`virtio-blk`* | **Yes** | **Yes** | **Yes** |
|
||||
| *`virtio-scsi`* | **Yes** | No | **Yes** |
|
||||
| *`virtio-fs`* | **Yes** | No | **Yes** |
|
||||
| *`virtio-net`* | **Yes** | **Yes** | **Yes** |
|
||||
| *`virtio-keyboard`* | **Yes** | No | **Yes** |
|
||||
| *`virtio-tablet`* | **Yes** | No | **Yes** |
|
||||
| *Chipset* | i440fx, Q35, virt | Q35 | i440fx, Q35, virt |
|
||||
| *Platform firmware* | [SeaBIOS](/virt/vm/firmware#seabios) [OVMF](/virt/vm/firmware#ovmf) [RHF](/virt/vm/firmware#rust-hypervisor-firmware) [^1] | [OVMF](/virt/vm/firmware#ovmf) | [SeaBIOS](/virt/vm/firmware#seabios) [OVMF](/virt/vm/firmware#ovmf) [RHF](/virt/vm/firmware#rust-hypervisor-firmware) |
|
||||
| *virtio-gpu* | **Yes** | No | No |
|
||||
| *virtio-video* | *Upcoming* | No | No |
|
||||
| *virtio-snd* | *Upcoming* | No | No |
|
||||
| *virtio-blk* | **Yes** | **Yes** | **Yes** |
|
||||
| *virtio-scsi* | **Yes** | No | **Yes** |
|
||||
| *virtio-fs* | **Yes** | No | **Yes** |
|
||||
| *virtio-net* | **Yes** | **Yes** | **Yes** |
|
||||
| *virtio-keyboard* | **Yes** | No | **Yes** |
|
||||
| *virtio-tablet* | **Yes** | No | **Yes** |
|
||||
|
||||
[^1]: RHF stands for the Rust Hypervisor Firmware
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ editor: markdown
|
||||
dateCreated: 2021-11-13T11:58:19.844Z
|
||||
---
|
||||
|
||||
# Paths on Linux
|
||||
# Virtualization-related folders on Fedora-related Linux distributions
|
||||
|
||||
This page lists where most of the stuff related to virtualization is located on a Linux operating system. This is based on Fedora. But it should be similar for other distributions.
|
||||
|
||||
|
||||
47
virt/host/vmm.md
Normal file
47
virt/host/vmm.md
Normal file
@ -0,0 +1,47 @@
|
||||
|
||||
# KVM-related virtual machine monitors
|
||||
|
||||
The Kernel-based Virtual Machine (KVM) module for Linux can be leveraged by many virtual machine monitors (VMMs) to achieve near native performance.
|
||||
|
||||
### QEMU
|
||||
|
||||
[QEMU](https://wiki.qemu.org/) is a very popular emulator which can be used alongside to KVM to leverage hardware-assisted acceleration as found in modern CPUs. In this mode, as used as a virtualizer in QEMU lingo, it can run guest code directly on the host CPU.
|
||||
|
||||
### crosvm
|
||||
|
||||
crosvm is the Chrome OS Virtual Machine Monitor. It is integrated with the Chromium Operating System
|
||||
|
||||
### cloud-hypervisor
|
||||
|
||||
### firecracker
|
||||
|
||||
## Comparaison
|
||||
|
||||
See Joplin note under Phyllome OS
|
||||
|
||||
| | `QEMU` | `crosvm` | `cloud-hypervisor` |
|
||||
| :- | :-: | :-: | :-: |
|
||||
| *Firmware* | [SeaBIOS](/virt/vm/firmware#seabios) / [OVMF](/virt/vm/firmware#ovmf) | [SeaBIOS](/virt/vm/firmware#seabios) / [OVMF](/virt/vm/firmware#ovmf) | Modified [OVMF](/virt/vm/firmware#ovmf) / [RHF](/virt/vm/firmware#rust-hypervisor-firmware) |
|
||||
| *PS/2 devices* | **Yes** | **Yes** | No |
|
||||
| *USB Controller* | **Yes** | **Yes** | No |
|
||||
| *SATA Controller* | No | **Yes** | No |
|
||||
| *IDE Controller* | **Yes** | No | No |
|
||||
| *Floppy Controller* | **Yes** | No | No |
|
||||
| *TPM Support* | No | **Yes** | No? |
|
||||
| *PCI-Express Bus* | No | **Yes** | **Yes** |
|
||||
| *PCI Bus* | **Yes** | No? | No? |
|
||||
| *Virtual Function I/O* | No | **Yes** | **Yes** |
|
||||
|
||||
|
||||
## Resources
|
||||
|
||||
QEMU documentation
|
||||
|
||||
https://github.com/firecracker-microvm/firecracker/blob/main/docs/vsock.md
|
||||
|
||||
|
||||
https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md
|
||||
|
||||
---
|
||||
|
||||
*[**Go to parent page**](https://wiki.phyllo.me/)*
|
||||
@ -13,13 +13,14 @@ dateCreated: 2021-11-13T11:58:43.776Z
|
||||
## Table of Contents
|
||||
|
||||
1. [*Device*](/virt/lexicon#device)
|
||||
2. [*Emulator*](/virt/lexicon#emulator)
|
||||
3. [*Hardware-assisted virtualization*](/virt/lexicon#hardware-assisted-virtualization)
|
||||
4. [*Hypervisor*](/virt/lexicon#hypervisor)
|
||||
5. [*Nested-virtualization*](/virt/lexicon#nested-virtualization)
|
||||
6. [*Paravirtualization*](/virt/lexicon#paravirtualization)
|
||||
7. [*Virtual machine*](/virt/lexicon#virtual-machine)
|
||||
8. [*Virtualization*](/virt/lexicon#virtualization)
|
||||
1. [*Emulator*](/virt/lexicon#emulator)
|
||||
1. [*Hardware-assisted virtualization*](/virt/lexicon#hardware-assisted-virtualization)
|
||||
1. [*Firmware*](/virt/lexicon#firmware)
|
||||
1. [*Hypervisor*](/virt/lexicon#hypervisor)
|
||||
1. [*Nested-virtualization*](/virt/lexicon#nested-virtualization)
|
||||
1. [*Paravirtualization*](/virt/lexicon#paravirtualization)
|
||||
1. [*Virtual machine*](/virt/lexicon#virtual-machine)
|
||||
1. [*Virtualization*](/virt/lexicon#virtualization)
|
||||
|
||||
## Device
|
||||
|
||||
@ -28,24 +29,23 @@ Devices are computer components that can be attached to machines. They can be cl
|
||||
| | Physical hardware | Emulated: model-based | Emulated: paravirtual |
|
||||
| :- | :-: | :-: | :-: |
|
||||
| *Design* | Specific | Specific | Generic |
|
||||
| *Type* | Silicon-based | Software-based | Software-based |
|
||||
| *Type* | Silicon-based | Software-based | Software-based |
|
||||
|
||||
* **Physical**
|
||||
* **Physical**
|
||||
|
||||
* Physical components refer to devices that can be attached to a system. For instance, a dedicated physical graphics card attached to a physical system can be directly attached to a virtual machine, which then becomes responsible for managing it, a technique called *passthrough*. The PCI-SIG standards provide IOMMU-related specifications to allow a host operating system to not have a driver for a particular device[^4] and passthrough the device to the guest. The guest will have a device with nearly native performance, and use the standard vendor's drivers for the device.
|
||||
* The PCI-SIG standards also provide a way to partition compatible devices using so-called Virtual Functions (VFs). In this case, the host manages the way a physical device is used by the guest. Both host and guest must have specific device drivers. It offers nearly native performance.
|
||||
* Physical components refer to devices that can be attached to a system. For instance, a dedicated physical graphics card attached to a physical system can be directly attached to a virtual machine, which then becomes responsible for managing it, a technique called *passthrough*. The PCI-SIG standards provide IOMMU-related specifications to allow a host operating system to not have a driver for a particular device[^4] and passthrough the device to the guest. The guest will have a device with nearly native performance, and use the standard vendor's drivers for the device.
|
||||
|
||||
* The PCI-SIG standards also provide a way to partition compatible devices using so-called Virtual Functions (VFs). In this case, the host manages the way a physical device is used by the guest. Both host and guest must have specific device drivers. It offers nearly native performance.
|
||||
|
||||
[^4]: Thanks to Pasha Tatashin for pointing this out.
|
||||
|
||||
* **Emulated**
|
||||
* **Emulated**
|
||||
|
||||
* Model-based
|
||||
* Model-based emulated hardware are designed after real devices, but are made out of computer code, not silicon. The i440fx and Q35 chipsets[^5] are both instances of emulated hardware. This is the slowest (but most compatible) way to provide a device to a guest. An emulated GPU is not going to be fast enough in an emulated mode to do 3D rendering.
|
||||
|
||||
* Model-based emulated hardware are designed after real devices, but are made out of computer code, not silicon. The i440fx and Q35 chipsets[^5] are both instances of emulated hardware. This is the slowest (but most compatible) way to provide a device to a guest. An emulated GPU is not going to be fast enough in an emulated mode to do 3D rendering.
|
||||
* **Paravirtual**
|
||||
|
||||
* Paravirtual
|
||||
|
||||
* Paravirtual hardware, also known as paravirtualized Virtual I/O devices or simply virtio, are also made out of computer code. Contrary to emulated hardware, they function as a generic piece of software-based hardware which doesn't replicate a specific hardware component.
|
||||
* Paravirtual hardware, also known as paravirtualized Virtual I/O devices or simply virtio, are also made out of computer code. Contrary to emulated hardware, they function as a generic piece of software-based hardware which doesn't replicate a specific hardware component.
|
||||
|
||||
[^5]: The Q35 chipset, contrary to i440fx, provides a PCI Express (PCIe) bus. Alas, the i440fx, despite its limitations to PCI-only, does support passthrough of PCIe devices, as long as the driver follows suit. Thanks to Stefan Reiter for pointing that out.
|
||||
|
||||
@ -57,6 +57,10 @@ QEMU[^1] is a popular emulator that can act as a simulator or virtual machine mo
|
||||
|
||||
[^1]: In its [online manual](https://qemu.readthedocs.io/en/latest/about/index.html), QEMU is described as follows: “QEMU is a generic and open source machine emulator and virtualizer. QEMU can be used in several different ways. The most common is for “system emulation”, where it provides a virtual model of an entire machine (CPU, memory and emulated devices) to run a guest OS. In this mode the CPU may be fully emulated, or it may work with a hypervisor such as KVM, Xen, Hax or Hypervisor. Framework to allow the guest to run directly on the host CPU.”
|
||||
|
||||
## Firmware
|
||||
|
||||
Firmware are software that are tightly integrated with the hardware. Almost all devices are shipping with some kind of firmware associated to it. For instance, motherboards include such programs, which in their case is tasked to properly boot hardware devices such as RAM modules, check their state and make them ready-to-use by an operating system.
|
||||
|
||||
## Hardware-assisted virtualization
|
||||
|
||||
Hardware-assisted virtualization is a feature of certain computer hardware made to take advantage of virtualization.
|
||||
@ -75,12 +79,12 @@ The hypervisor and VMM work in tandem with emulators, which provide them virtual
|
||||
|
||||
As of 2021, there are two major open-source hypervisor that are both are able to leverage hardware-assisted virtualization:
|
||||
|
||||
- **Xen**[^2] (2003-).
|
||||
- **Kernel-based Virtual Machine module**[^3] (KVM) for Linux (2007-).
|
||||
- **Xen**[^2] (2003-).
|
||||
- **Kernel-based Virtual Machine module**[^3] (KVM) for Linux (2007-).
|
||||
|
||||
[^2]: Originally developed at Cambridge, Xen was first released in 2003. It is primarily used alongside Linux, although Xen is compatible with other operating systems as well. Interestingly, it can function on hardware that lacks hardware-assisted virtualization. AWS is by far the largest Xen shop, but is slowly shifting towards KVM.
|
||||
|
||||
[^3]: The Kernel-based Virtual Machine (KVM) module for Linux was first developed by Qumranet, Inc, a former software company focusing on Desktop virtualization which was later acquired by Red Hat. Qumranet, Inc has also developed the SPICE protocol, which among other things allows for interaction with a guest display machine over a network.
|
||||
[^3]: The Kernel-based Virtual Machine (KVM) module for Linux was first developed by Qumranet, Inc, a former software company focusing on Desktop virtualization which was later acquired by Red Hat. Qumranet, Inc has also developed the SPICE protocol, which among other things allows for interaction with a guest display machine over a network.
|
||||
|
||||
## Nested-virtualization
|
||||
|
||||
@ -107,9 +111,11 @@ machines.
|
||||
|
||||
There are roughly three types of virtualization:
|
||||
|
||||
* **Simulation or emulation**: when a computer is fully emulated and can be made to look like any device to an operating system
|
||||
* **Partition**: when computer resources are split such that each operating system can only see a subset of available hardware resources
|
||||
* **Paravirtualization**: when both hardware and software-assisted virtualization is being used. In this case, the guest is aware that it is running in the virtualized environment, and acts accordingly.
|
||||
- **Simulation or emulation**: when a computer is fully emulated and can be made to look like any device to an operating system
|
||||
|
||||
- **Partition**: when computer resources are split such that each operating system can only see a subset of available hardware resources
|
||||
|
||||
- **Paravirtualization**: when both hardware and software-assisted virtualization is being used. In this case, the guest is aware that it is running in the virtualized environment, and acts accordingly.
|
||||
|
||||
Virtualization is used to better isolate resources on a physical computer and to distribute them across various workloads, enabling better use of resources through consolidation. For instance, with virtualization, multiple operating systems can run concurrently on a physical machine.
|
||||
|
||||
|
||||
@ -1,179 +0,0 @@
|
||||
---
|
||||
title: Display
|
||||
description: How to access a virtual machine's display
|
||||
published: true
|
||||
date: 2023-10-15T15:11:00.161Z
|
||||
tags:
|
||||
editor: markdown
|
||||
dateCreated: 2022-07-31T09:22:05.854Z
|
||||
---
|
||||
|
||||
# Display
|
||||
|
||||
A virtual display can be attached to a virtual machine. It is a must-have for non-headless scenarios.
|
||||
|
||||
## Display types
|
||||
|
||||
### SDL display
|
||||
|
||||
The [Simple DirectMedia Layer](https://www.libsdl.org/) (SDL)-powered display is a local-only low-latency display.
|
||||
|
||||
> The SDL display is only avalable with virtual machines created using the QEMU/KVM **User Session**.
|
||||
{.is-info}
|
||||
|
||||
> Mouse grab does not currently work with the SDL display
|
||||
{.is-warning}
|
||||
|
||||
> The display resolution of your guest display should not exceed that of your physical screen
|
||||
{.is-info}
|
||||
|
||||
#### SELinux-related configuration
|
||||
|
||||
By default, SELinux will block access to X Windows Server for the virtualization stack. An exception has to be set.
|
||||
|
||||
* Set new rule
|
||||
|
||||
```
|
||||
sudo setsebool -P virt_use_xserver 1
|
||||
```
|
||||
|
||||
* Do some magic trick
|
||||
|
||||
```
|
||||
sudo ausearch -c 'qemu-system-x86' --raw | audit2allow -M my-qemusystemx86
|
||||
k
|
||||
```
|
||||
|
||||
* And another one
|
||||
|
||||
```
|
||||
sudo semodule -X 300 -i my-qemusystemx86.pp
|
||||
```
|
||||
|
||||
#### SDL XML configuration
|
||||
|
||||
* The default display can be identified using `echo $DISPLAY`.
|
||||
|
||||
```
|
||||
$ echo $DISPLAY
|
||||
:0
|
||||
```
|
||||
|
||||
The same applies to `xauth`. On Wayland, it would look like that.
|
||||
|
||||
```
|
||||
$ echo $XAUTHORITY
|
||||
/run/user/1000/.mutter-Xwaylandauth.ARIY51
|
||||
```
|
||||
|
||||
* Example of an XML SDL configuration, with OpenGL enabled. This example requires a 3D-capable graphic card to be attached to the guest computer, such as `virtio-gpu`.
|
||||
|
||||
```
|
||||
<graphics type="sdl" display=":0" xauth="/run/user/1000/.mutter-Xwaylandauth.ARIY51" fullscreen="yes">
|
||||
<gl enable="yes"/>
|
||||
</graphics>
|
||||
```
|
||||
|
||||
> The fullscreen attribute is not honored at the moment
|
||||
{.is-warning}
|
||||
|
||||
### D-Bus display
|
||||
|
||||
[D-Bus](https://www.freedesktop.org/wiki/Software/dbus/) is a desktop-oriented middleware that can be used to create a display for a virtual machine.
|
||||
|
||||
#### Libvirt
|
||||
|
||||
* Add a D-Bus video backend and add enable for OpenGL:
|
||||
|
||||
```
|
||||
<graphics type="dbus">
|
||||
<gl enable="yes"/>
|
||||
</graphics>
|
||||
```
|
||||
|
||||
> This equates to `-display dbus,gl=on` in QEMU
|
||||
>
|
||||
{.is-info}
|
||||
|
||||
When the virtual machine is launched, a specific D-Bus address will be choosen, as well as a rendering device:
|
||||
|
||||
```
|
||||
<graphics type="dbus" address="unix:path=/run/user/1000/libvirt/qemu/run/dbus/8-user-d-bus-dbus.sock">
|
||||
<gl enable="yes" rendernode="/dev/dri/renderD128"/>
|
||||
</graphics>
|
||||
```
|
||||
|
||||
* Add a D-Bus audio backend:
|
||||
|
||||
```
|
||||
<graphics type="dbus">
|
||||
<audio id="1">
|
||||
</graphics>
|
||||
```
|
||||
|
||||
#### Connect to the D-Bus display
|
||||
|
||||
A third-party tool is required to interact to the D-Bus display.
|
||||
|
||||
[Libmks](https://gitlab.gnome.org/GNOME/libmks), which is under development, is such a tool.
|
||||
|
||||
> Due to [a bug](https://gitlab.gnome.org/GNOME/libmks/-/issues/16), it is currenlty only possible to connect a D-Bus display with plain QEMU
|
||||
{.is-warning}
|
||||
|
||||
Libmks has to be built from source.
|
||||
|
||||
- Clone the repository
|
||||
|
||||
```
|
||||
git clone https://gitlab.gnome.org/GNOME/libmks
|
||||
```
|
||||
|
||||
- Change directory
|
||||
|
||||
```
|
||||
cd libmks
|
||||
```
|
||||
|
||||
- Build it
|
||||
|
||||
```
|
||||
meson setup build
|
||||
cd build
|
||||
ninja
|
||||
```
|
||||
|
||||
- Launch a diskless virtual machine
|
||||
|
||||
```
|
||||
qemu-system-x86_64 \
|
||||
-enable-kvm \
|
||||
-machine q35 \
|
||||
-drive if=pflash,format=raw,readonly=on,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \
|
||||
-cpu host \
|
||||
-device virtio-vga-gl \
|
||||
-m 4G \
|
||||
-smp 2,sockets=1,dies=1,cores=2,threads=1 \
|
||||
-display dbus,gl=on \
|
||||
-device virtio-tablet-pci \
|
||||
-device virtio-keyboard-pci \
|
||||
```
|
||||
|
||||
- From another terminal tab or window, launch the previously built MKS using the following command
|
||||
|
||||
```
|
||||
./build/tools/mks
|
||||
```
|
||||
|
||||
As there is no Live ISO or disk attached to the virtual machine, you will eventually land in the UEFI shell.
|
||||
|
||||
## Resources
|
||||
|
||||
* [Detailed presentation](https://bootlin.com/pub/conferences/2016/meetup/dbus/josserand-dbus-meetup.pdf) on D-Bus
|
||||
* [Official resource](https://libvirt.org/formatdomain.html#graphical-framebuffers) for libvirt-compatible displays, including various XML examples
|
||||
* [Libmks](https://gitlab.gnome.org/chergert/libmks) provides a "Mouse, Keyboard, and Screen" to QEMU using the D-Bus device support in QEMU and GTK 4.
|
||||
* [QEMU D-Bus display experiment](https://gitlab.com/marcandre.lureau/qemu-display/) is a WIP Rust crates to interact with a -display dbus QEMU
|
||||
* [SDL graphics](https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#SDL_Graphics)
|
||||
|
||||
---
|
||||
|
||||
*[**Go to parent page**](https://wiki.phyllo.me/)*
|
||||
@ -10,34 +10,37 @@ dateCreated: 2022-01-25T14:50:10.751Z
|
||||
|
||||
# Platform firmware
|
||||
|
||||
Virtual devices, including virtual chipsets, are shipping alongside platform firmware.
|
||||
Virtual devices, including virtual chipsets, are shipping alongside platform firmware.
|
||||
|
||||
> ***Definition**: Firmware are software that are tightly integrated with the hardware. Almost every devices are shipping with some kind of firmware associated to it. For instance, motherboards include such programs, which in their case is tasked to properly boot hardware devices such as RAM modules, check their state and make them ready-to-use by an operating system*
|
||||
{.is-info}
|
||||
|
||||
## Available platform firmware for virtual machines
|
||||
## Common platform firmware for virtual machines
|
||||
|
||||
### SeaBIOS
|
||||
|
||||
[SeaBIOS](https://www.seabios.org/SeaBIOS) is an implementation of a x86 BIOS which relies on [Coreboot](https://www.coreboot.org/) and can be used to boot virtual machines. It is incompatible with UEFI. It is also simpler.
|
||||
[SeaBIOS](https://www.seabios.org/SeaBIOS) is an implementation of an x86 BIOS which relies on [coreboot](https://www.coreboot.org/). It is used for legacy systems, but also to specialized and cloud optimized guests systems which don't require UEFI.
|
||||
|
||||
### OVMF
|
||||
|
||||
[OVMF](https://github.com/tianocore/tianocore.github.io/wiki/OVMF), which stands for Open Virtual Machine Firmware, is a UEFI-compatible firmware. It is based on the larger [TianoCore](https://www.tianocore.org/) project, which provides an open-source implementation of a platform firmware that follows UEFI specifications. It is the default method to boot UEFI-based operating systems in a virtual machine.
|
||||
[OVMF](https://github.com/tianocore/tianocore.github.io/wiki/OVMF), which stands for Open Virtual Machine Firmware, is a UEFI-compatible firmware.
|
||||
|
||||
It is based on the [TianoCore](https://www.tianocore.org/) project, which provides an open-source implementation of a platform firmware that follows UEFI specifications.
|
||||
|
||||
It is the default method to boot UEFI-based operating systems in a virtual machine.
|
||||
|
||||
### Rust Hypervisor Firmware
|
||||
|
||||
The [Rust Hypervisor Firmware](https://github.com/cloud-hypervisor/rust-hypervisor-firmware) (RHF) is a UEFI-compatible firmware. It is focused on simplicity and performance and is designed for virtual workloads. It is tightly integrated with the Cloud Hypervisor.
|
||||
The [Rust Hypervisor Firmware](https://github.com/cloud-hypervisor/rust-hypervisor-firmware) (RHF) is a UEFI-compatible firmware. It is focused on simplicity and performance and is designed to run cloud-centric operating systems.
|
||||
|
||||
## Comparison
|
||||
It is developed alongside the Cloud Hypervisor.
|
||||
|
||||
## Supported features
|
||||
|
||||
| | SeaBIOS | OVMF | RHF |
|
||||
| :-- | :-: | :-: | :-: |
|
||||
| *BIOS* | **Yes** | No | No |
|
||||
| *UEFI* | No | **Yes** | **Yes** |
|
||||
| *Secureboot* | No | **Yes** | **Yes** |
|
||||
| *Chipset support* | [`i440fx`](/virt/vm/chipset#i440fx) / [`Q35`](/virt/vm/chipset#q35) | [`i440fx`](/virt/vm/chipset#i440fx) / [`Q35`](/virt/vm/chipset#q35) | [`Q35`](/virt/vm/chipset#q35)? / [`virt`](/virt/vm/chipset#virt) |
|
||||
| *Guest support* | **Linux** / **Windows** | **Linux** / **Darwin** / **Windows** | **Linux** / **Windows** |
|
||||
| *Secure Boot* | No | **Yes** | ? |
|
||||
| *Chipset* | [i440fx](/virt/vm/chipset#i440fx), [Q35](/virt/vm/chipset#q35) | [i440f](/virt/vm/chipset#i440fx), [Q35](/virt/vm/chipset#q35) | [virt](/virt/vm/chipset#virt) |
|
||||
| *Guests* | **Linux**, **Windows** | **Linux**, **Darwin**, **Windows** | **Linux**, **Windows** |
|
||||
| *Virtual Function I/O (VFIO)* | No | **Yes** | **Yes** |
|
||||
|
||||
---
|
||||
|
||||
@ -10,19 +10,19 @@ dateCreated: 2021-11-13T17:52:22.554Z
|
||||
|
||||
# Graphic cards
|
||||
|
||||
Phyllome leverages 3D acceleration within guest operating systems extensively, in three different modes depending on the situation.
|
||||
Phyllome leverages 3D acceleration within guest operating systems extensively, in three different modes depending on the context.
|
||||
|
||||
* **vfio-pci** : Passing through a complete physical Graphical Processing Unit (GPU) to the guest via the `vfio-pci` driver
|
||||
* **vfio-mdev** : Sharing a fraction of a compatible physical GPU such as those using [single-root input/output virtualization](https://en.wikipedia.org/wiki/Single-root_input/output_virtualization) (SR-IOV), via the `vfio-mdev` driver
|
||||
* **vfio-gpu** : Using some capabilities of the host GPU, via the `vfio-gpu` driver, which creates a virtual GPU as is used in Chromium OS and Spectrum OS
|
||||
* **vfio-pci** : Passing through a physical Graphical Processing Unit (GPU) to the guest via the `vfio-pci` driver
|
||||
* **vfio-mdev** : Create multiple vGPUs that can then be passed through to multiple guests. It does require a compatible GPU
|
||||
* **virtio-gpu** : Expose capabilities of the host GPU to the guest via the `virtio-gpu` driver. Compatible with most GPUs but not many guests
|
||||
|
||||
| Description | `vfio-pci` | `vfio-mdev` | `vfio-gpu` |
|
||||
| Description | vfio-pci | vfio-mdev | vfio-gpu |
|
||||
|---|---|---|---|
|
||||
| *Performance* | Near-native performance and full features set | Near-native performance and full features set | Degraded performance and limited features set |
|
||||
| *Guests support* | UNIX and non-UNIX guests | UNIX and non-UNIX guests | Works only on selected UNIX guests |
|
||||
| *Driver* | No special driver in the guest | No special driver in the guest | Requires a special driver in the guest |
|
||||
| *Driver* | No specialized driver in the guest | No specialized driver in the guest | A special driver in the guest is required |
|
||||
| *Number of host GPUs* | Two GPUs in most situations | A single GPU | A single GPU |
|
||||
| *GPU support* | Mostly GPU agnostic | Recent Intel integrated GPUs and some professional grade Nvidia GPUs | Mostly GPU agnostic |
|
||||
| *GPU support* | Mostly GPU agnostic | Recent Intel integrated GPUs and some professional-grade Nvidia GPUs. Some consumer GPUs can be unlocked | Mostly GPU agnostic |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -21,12 +21,12 @@ In this section, the focus is oriented towards Virtual I/O Devices (VIRTIO), bet
|
||||
|
||||
### Graphical frame buffer
|
||||
|
||||
* [`virtio-gpu`](/virt/virtio/snd)
|
||||
* [`virtio-gpu`](/virt/virtio/gpu)
|
||||
* Paravirtual GPU that provides a subset of the host GPU capabilities to a guest virtual machine
|
||||
|
||||
### Video decoding/encoding
|
||||
|
||||
* [`virtio-video`](/virt/virtio/snd)
|
||||
* [`virtio-video`](/virt/virtio/video)
|
||||
* Paravirtual video device that provides encoding and decoding capabilities to a guest virtual machine
|
||||
|
||||
### Sound
|
||||
@ -77,7 +77,7 @@ In this section, the focus is oriented towards Virtual I/O Devices (VIRTIO), bet
|
||||
| *`virtio-wayland`* | No | No | ? |
|
||||
| *`virtio-console`* | **Yes** | **Yes** | **Yes** |
|
||||
|
||||
## Resourcess
|
||||
## Resources
|
||||
|
||||
* Specifications
|
||||
* [Version 1.0](https://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html) of the specification for Virtual I/O Devices
|
||||
|
||||
Reference in New Issue
Block a user