4 ms·

Yes and no. Similar in functionality, different in implementation. So you do get things like IOMMU etc. but you need a different software implementation to make

Yes and no. Similar in functionality, different in implementation. So you do get things like IOMMU etc. but you need a different software implementation to make use of it, even if only to use the different ISA and setup procedures. Imagine it like this: ┌─────────────────────────────────────┐ │higher-level software to abstract it │ ├────────────────────────────▲────────┤ ├───▼─────────────────────────────────┤ │low-level software to make use of it │ ├────────────────────────────▲────────┤ ├───▼─────────────────────────────────┤ │hardware with virtualisation support │ └─────────────────────────────────────┘ Even within the same architecture you might need different low-level interfacing software to make use of it. Even a type-1 hypervisor like Xen would need to know a bit about the specifics of the hardware to know what features exist and how to use them. Then you get some higher level abstractions that allow you to use a virtualisation interface to make use of the system without having to re-invent that interface every time some new hardware gets released. So if you have libvirt, you have a high-level abstraction for multiple hypervisors (like KVM and Xen) which in turn know how to interact with various hardware implementations to actually have it act the way we want it. On macOS there were essentially two low-level implementations, one for ARM and one for Intel, and a higher-level abstraction, Hypervisor.framework, that lets you simply "create" virtual machine instances, which then make use of the various virtualisation features depending on the underlying hardware. In the early days, the implementations between AMD and Intel were so different that you often needed specific builds for one or the other implementations, and you couldn't have both loaded at the same time (even if just 1 active and every other implementation inactive).

saagarjha 4y ago
Hypervisor has a core API that is shared across Intel and Apple silicon (e.g. hv_vcpu_run) and then each platform has its own additions on top of this (for example, on Intel platforms you can prod the VMCS). On top of this is the Virtualization framework, which provides a largely unified API to run VMs (dealing with things like screens, pointing devices, etc.) that and treating the actual virtualized processor as an implementation detail, besides you having to provide an image that matches the host architecture. The linked code here uses Virtualization.

saagarjha 4y ago

Hypervisor has a core API that is shared across Intel and Apple silicon (e.g. hv_vcpu_run) and then each platform has its own additions on top of this (for example, on Intel platforms you can prod the VMCS). On top of this is the Virtualization framework, which provides a largely unified API to run VMs (dealing with things like screens, pointing devices, etc.) that and treating the actual virtualized processor as an implementation detail, besides you having to provide an image that matches the host architecture. The linked code here uses Virtualization.