No judgement of not knowing but para-virtualization is not emulation and it is not a new or niche technology either. I think IBM was doing it in the 60s (might be off base with that factoid because modern-ish operating systems like the RC4000 weren't even a thing until the late 60s). It has simply been superseded by hardware assisted vt that allows for multiple "ring-0" guests.
There is a greater overhead and a limited scope when using paravirtualization. But that doesn't mean it is a relic, in fact you can try it right now in Virtualbox. I also believe that the Linux KVM has para-virtualization optimizations if the guest is Linux and the bare metal doesn't support hardware VT.
I'm confused, are you sure you've responded to the right comment? No one is talking about paravirtualization in this thread. As I take it, the parent comment was suggesting that Apple was faking virtualization with some kind of software trick in the demo, which isn't what paravirtualization is about.
Paravirtualization is a general optimization technique for VMs that allows the guest OS to better communicate its intent to the hypervisor through the use of hypercall APIs, sparing the guest OS from having to issue many series of privileged CPU instructions that each have to be trapped and handled by the hypervisor. It saves time because going back and forth between the hypervisor and the guest OS is an expensive operation, and reducing the number of times it happens helps a lot. It's not a simple replacement for hardware assisted virtualization or the other way around.
Perhaps I misunderstood. Here is the logic flow I followed:
(1) Apple has a virtualization framework that can "...boot and run a Linux-based operating system on an Apple silicon or Intel-based Mac computer."
(2) The virtualization framework for arm-based Macs will virtualize arm-Linux and x86-based macs would virtualize x86-linux. There maybe a semantic issue here if you believe that this api would also allow the "virtualization" of x86-linux on arm. That would not be considered virtualization to my best understanding of the definition.
(3) Looking at Apple's VZVirtualMachineConfiguration, VZVirtualMachine and "Virtualization Constants" there is nothing apparently exposing the underlying virtualization mechanism. So we don't know if Apple uses hardware (ring -1 in x86 parlance) or software virtualization (almost always para-virtualization) under the hood. Likely it uses both depending on the context.
(4) We know that Apple's current dev kit hardware (A12z) doesn't support hardware virtualization. Hardware virtualization is commonly referred to as the "Virtualization Host Extension" in arm64 parlance.
(5) We know that Apple demoed virtualization on arm with what appeared to be a arm64 ubuntu guest.
(6) Your original message said that you believed they weren't using an a12z for the demo, likely because its aforementioned lack of hardware virtualization.
(7) The comment below yours suggest that "One can certainly write software that virtualizes another machine". They were more than likely referring to para-virtualzation in their comment. I don't know any other blanket type of software virtualization.
(8) You responded saying you didn't know what software virtualization was, it is almost always para-virtualization. Para-virtualziation does not require a hardware hypervisor and predates all hardware virtualization technologies.
While there is full-hardware virtualization, it basically never a thing that happens anymore because of the rather large overhead. I don't know of any modern virtualization software that offers full software virtualization. Especially if your guest is Linux.
> (6) Your original message said that you believed they weren't using an a12z for the demo
I never claimed this
> (7) The comment below yours suggest that "One can certainly write software that virtualizes another machine". They were more than likely referring to para-virtualzation in their comment.
Well, yes and no. Virtualization (in the context of VMs) is about sharing the hardware between multiple OSes, so the statement about "virtualizing another machine" didn't even remotely make any sense. This led to my original comment, "emulation isn't virtualization."
And one small thing, it was the comment above mine, not below.
> (8) You responded saying you didn't know what software virtualization was, it is almost always para-virtualization.
Where can I find refereces to this term that supports this statement? I looked, and found the term "software virtualization" being used to refer to containerization and programming language runtimes, but not VMs.
You are correct about (6)! Apologies different user!
7/8 together. A Google scholar search of "software virtualization" or "software virtualization para virtualization" returned the following (plus many more) that refer to software virtualization in the same way I meant:
Finally I dopishly wrote "full hardware virtualization" when I meant "full virtualization", but for posterity here is VMware doc on it vs paravirtualzation vs hardware-assisted virtualzation:
https://www.vmware.com/content/dam/digitalmarketing/vmware/e...
Paravirtualization is relevant if the CPU does not support full virtualization - Xen was originally designed to use PV because it was very difficult to make x86 VMs fast because unmodified guest OSs required slow emulation. See section 2 of https://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xens...
You may be confusing the concept of hardware-assisted virtualization with full virtualization. Moreover, the famous Xen paper you've linked to never claimed that x86 didn't support full-virtualization because it did thanks to VMWare.
VMware didn't do full virtualization - it couldn't because x86 did not support it at that time! There were privileged instructions that did not cause a trap, and so which could not be virtualized using the normal trap-to-monitor technique. VMware used dynamic translation to JIT the guest kernel so that it did not execute privileged instructions, and so that it would run much faster than a simple emulator. This is explained in the Xen paper and also in https://inst.eecs.berkeley.edu//~cs252/sp17/papers/vmware.pd...
> VMware [10] and Connectix [8] both virtualize commodity PC hardware, allowing multiple operating systems to run on a single host. All of these examples implement a full virtualization of (at least a subset of) the underlying hardware, rather than paravirtualizing and presenting a modified interface to the guest OS.
And no, I haven't forgotten about binary translation. As you mention, it was only used to replace privileged instructions and not a full-blown CPU emulator.
VMware VMs still ran native CPU instructions, and the overhead incurred by translation is a whole different matter unrelated to my original point.
There is a greater overhead and a limited scope when using paravirtualization. But that doesn't mean it is a relic, in fact you can try it right now in Virtualbox. I also believe that the Linux KVM has para-virtualization optimizations if the guest is Linux and the bare metal doesn't support hardware VT.