Note that this is about Virtualization.framework (Apple's first party VMM). OpenBSD worked on Hypervisor.framework + qemu since a very long time.

Good point. The naming of those frameworks is sooo confusing. IMHO, nearly impossible to not mix them up.

My mental model is that each of these covers a different layer of the stack, from lowest to highest:

* hypervisor-framework handles the hypervisor bits, like creating virtual machines, virtualising hardware resources, basically a C API on top of Apple's hypervisor

* virtualization-framework is a higher-level API, meant to make it easy to run a full-blown VM with an OS and hardware integration, without having to reinvent the integration with lower-level primitives that hypervisor-framework provides

* containerization-framework uses virtualization-framework to run Linux containers on macOS in microVMs.

By analogy to not mix them up, it's a bit like KVM > QEMU > containerd.

Hope this helps!

Well, it help me. So thanks!

Out of my depth here. Is that the one Tahoe was introducing? What did it solve that was impossible before?

Virtualization.framework was introduced in Big Sur. It builds on top of Hypervisor.framework and is essentially Apple's QEMU (in some ways quite literally, it implements QEMU's pvpanic protocol for example). Before QEMU and other VMMs gained ARM64 Hypervisor.framework support, it was the only way to run virtual machines on ARM Macs and still is the only official way to virtualize ARM macOS.

The new Tahoe framework you're probably thinking of is Containerization, which is a WSL2-esque wrapper around Virtualization.framework allowing for easy installation of Linux containers.

>a WSL2-esque wrapper around Virtualization.framework allowing for easy installation of Linux containers.

So Linux is now a first class citizen on both Windows and Mac? I guess it really is true that 'if you can't beat em, join em.' Jobs must be rolling in his grave.

It's well supported by the architecture. You may be interested in:

- Lima - wsl2-like access to a virtual machine https://github.com/lima-vm/lima/blob/master/README.md

- vfkit - CLI creation and management of applehv VMs https://github.com/crc-org/vfkit

- podman machine - easily run x86 containers in CoreOs, via the podman CLI https://docs.podman.io/en/latest/markdown/podman-machine.1.h...

I mean to be fair, WSL1 and WSL2 are extremely successful engineering efforts by Microsoft. I can’t imagine having to go back to the Cygwin days.

I'm one of the few I think who really liked Cygwin. Far from perfect of course, but I even still prefer it to WSL depending on what I'm doing.

Oh good point. I mixed it up, UTM is using qemu under hood, but as someone mentioned now OpenBSD snapshot boots with qemu seemlesly. It's still virtualised though.

It can also use the apple native hypervisor.

Tried it earlier using UTM and the Apple hypervisor but didn’t boot.

The Nitro Hypervisor team is (mostly) in Berlin :)

The Nitro _card_ teams are elsewhere

Fair enough. The comment was about software, and to me the Nitro hypervisor is software while the Nitro card is hardware and firmware. ;-)

> Processor Trace

Apple uses their own design there currently instead of the Arm standard mechanism, which they'll maybe migrate to eventually...

FEAT_TRBE and FEAT_BRBE for the standard ones

* Or not, they don't use a standard PMU...

Note that sm_110 (Jetson Thor) has the tcgen05 ISA exposed (with TMEM and all) instead of the sm_120 model.

The ABI was stabilised for backwards compatibility since Windows Server 2022, but is not stable for earlier releases.

Is https://github.com/Samsung/ENNDelegate enough or is it TFLite/LiteRT only?

There's a MIG vGPU mode usable for this

Have you used it? How does it work? How do you drive it? We tried a lot of different things. Is it not paravirtualized, the way vGPUs are?

It works with SR-IOV instead of mdev afaik

Still needs some host SW to drive it but actually does static partitioning

IIRC it's usable through using the MIG-marked vGPU types

Notably, ConnectX-8 already has 200G PAM4 for 800G as a single port - and uses it for Infiniband.

Looks like it is so because it pre-dates 800G Ethernet ratification...

Not for prompt processing. Current Macs are really not great at long contexts

The specialty DRAM vendors (Nanya notably) will keep making DDR4 and earlier