[HN Gopher] Intel Virtualization and Apple Silicon
       ___________________________________________________________________
        
       Intel Virtualization and Apple Silicon
        
       Author : zdw
       Score  : 114 points
       Date   : 2022-03-26 15:44 UTC (2 days ago)
        
 (HTM) web link (www.highcaffeinecontent.com)
 (TXT) w3m dump (www.highcaffeinecontent.com)
        
       | herpderperator wrote:
       | > One advantage very specific to the low-level way ESXi works,
       | because there's no underlying operating system to get in the way,
       | is the ability to 'pass through' real hardware to the virtual
       | machine -- say a specific network card, or a USB hub. Or most
       | importantly for macOS: a GPU.
       | 
       | This is not at all specific to ESXi... you can do PCIe and USB
       | passthrough with qemu running on Linux. The operating system
       | doesn't get in the way.
        
         | jsolson wrote:
         | Quibbling a bit with the details here.
         | 
         | > This is not at all specific to ESXi... you can do PCIe and
         | USB passthrough with qemu running on Linux.
         | 
         | This is true.
         | 
         | > The operating system doesn't get in the way.
         | 
         | This isn't, really, at least not qemu does quite a bit of
         | fiddling under the hoot -- without VFIO or legacy KVM pass-
         | through, the operating system very much gets in the way. Linux
         | now provides facilities that allow qemu to pass through devices
         | -- that is, it provides the APIs necessary to move it back out
         | of the way.
         | 
         | I don't know to what extent ESXi looks like pure-kernel setup
         | of passthrough vruss KVM_ASSIGN_DEVICE versus VFIO -- that
         | would be quite interesting.
        
           | Melatonic wrote:
           | GPU passthrough specifically is tricky - I know ESXi does it
           | well but you of course have to dedicate a physical GPU to a
           | single VM. No sharing.
           | 
           | I know they were working on it with Hyper-V awhile back but
           | who knows howe well it works
        
       | samwillis wrote:
       | This is a great tutorial, thanks.
       | 
       | Slight aside, with the incredible performance possible with
       | Rosetta on Apple silicone, what are the chances of using it as
       | part of a virtual machine emulating x86-64 with similar
       | performance? I understand that Rosetta "recompiles" to ARM which
       | would probably be harder with a VM but I think it also does real-
       | time conversion to. I have no idea about he details but could
       | QEMU use Rosetta under the hood for emulation?
        
         | saagarjha wrote:
         | No, Rosetta is private and not exposed to third party
         | applications, and not really appropriate for supporting a VM
         | because it is designed for apps running in userspace.
        
           | samwillis wrote:
           | Are there any architectural lessons that could be learnt from
           | Rosetta and applied to QEMU?
           | 
           | So for example the "precompiling" of a binary, would that be
           | possible with a VM?
        
           | haberman wrote:
           | What about the hardware support for total store order that
           | Rosetta uses to provide the x86 concurrency model? Is that
           | something third-party implementations could conceivably use?
           | 
           | As long as that is available, it seems like third-party
           | virtualization software could get similar performance to
           | Rosetta, and potentially experiment with attempting to
           | support system-level CPU emulation.
        
         | wmf wrote:
         | Rosetta is deliberately just enough to run macOS/Intel apps on
         | macOS/ARM. It's theoretically possible for Apple to enhance
         | Rosetta to emulate a whole VM instead of a process but they
         | don't feel they need that so they're not going to.
        
         | shoo_pl wrote:
         | Literally second paragraph of the article mention QEMU-based
         | app that allows you to virtualise x64 machines on M1 - UTM:
         | 
         | https://mac.getutm.app/
         | 
         | The thing is, it only supports windows xp + windows 7, and not
         | 8/10/11 (those are supported as arm64). Apparently the amount
         | of work is massive (so are performance hits for the Windows
         | XP/7 when you run it).
         | 
         | It's one thing to emulate apps, another entirely to emulate
         | whole advanced OS.
        
           | samwillis wrote:
           | Yes, I read the article and was in fact aware of UTM, also
           | noted:
           | 
           | > the performance penalty is significant
           | 
           | I was asking the genuine question as to if it would be
           | theoretically possible to use Rosetta as part of the
           | emulation for a VM to potentially help it to perform better?
           | 
           | For example could a tool be installed within a guest OS that
           | effectively send binaries to Rosetta for translation before
           | execution?
           | 
           | It just seems to me that if Apple have done such an
           | incredible job with Rosetta wouldn't it be brilliant if it
           | was possible to use that within an emulated VM on Apple
           | silicone.
        
       | jwr wrote:
       | This is pure gold, thank you! I've been wondering what to do
       | about my VMware machines. Some run various windows apps, and one
       | runs Aperture, the only way to access my photo library after
       | Apple screwed me royally by abandoning Aperture. I didn't know
       | what ESXi was.
        
         | haxxorfreak wrote:
         | If you only need to run Aperture I've had good success using
         | Retroactive[1] on my M1 Max machine running Monterrey to patch
         | it to run under Rosetta. Almost everything works fine except
         | anything tied to iCloud and some of the video and slideshow
         | features. It's been great in letting me access my older photos
         | which have adjustments that I don't want to re-create in
         | Lightroom.
         | 
         | It will copy over the missing frameworks and modify the app so
         | the OS will run it even though it's unsupported, if you're
         | interested there is a technical breakdown that goes into
         | detail[2].
         | 
         | [1] https://github.com/cormiertyshawn895/Retroactive
         | 
         | [2] https://medium.com/@cormiertyshawn895/deep-dive-how-does-
         | ret...
        
       | vecplane wrote:
       | Please forgive my ignorance - what are the benefits of this
       | approach, as opposed to Remote Desktop into a Windows machine?
        
         | ErneX wrote:
         | The ability to have multiple VMs with many different operating
         | systems.
        
           | Melatonic wrote:
           | But you could easily do that with ESXi free running on your
           | home desktop, running multiple VM's (lets say Windows, linux,
           | BSD, etc etc) and then RDP from a mobile laptop to any of
           | those VM's.
        
       | kube-system wrote:
       | Running your VMs on another machine is not just good for
       | virtualizing Intel while using an Apple Silicon machine -- it's
       | also awesome just to offload resource utilization to another
       | machine. Throw Wireguard on your home network and you can work at
       | the coffee shop all day without plugging in to charge... and you
       | can close your laptop and your long-running tasks keep going.
        
         | Shakahs wrote:
         | Except now you require 2 machines and internet access instead
         | of just one machine. You could offload your VMs before too.
         | Keeping them all local and working offline are still important
         | capabilities.
        
           | kube-system wrote:
           | That depends on your use case, of course. I'm not going to be
           | working offline at a coffee shop anyway.
        
         | digitallyfree wrote:
         | Did this in university, where I carried a lightweight
         | disposable laptop and had a desktop workstation (and later a
         | server) at home. I used OpenVPN to remote in and got to smirk
         | at the students who either had slow builds, a heavy gaming
         | laptop, or had the money for a top-line MBP or similar.
         | 
         | Due to the slow upload speed of my DSL connection, this forced
         | me to become comfortable with TUI apps and a multiplixed
         | terminal environment, with the occassional use of Xpra when
         | absolutely necessary.
        
         | copperx wrote:
         | I use ZeroTier for that use case. Is Wireguard similar?
        
           | cassianoleal wrote:
           | ZeroTier does a lot more for you than pure Wireguard. OTOH,
           | Wireguard tends to have a lot more bandwidth than ZT in my
           | experience.
           | 
           | If you want a similar product to ZeroTier but one that uses
           | Wireguard under the hood, Tailscale is what I've been using
           | to connect to my home network.
        
           | artificialLimbs wrote:
           | Last I used ZT, it was pretty flaky on Windows. Network would
           | just stop working sometimes, client would bug out and I would
           | have to uninstall/reinstall. Slow speeds also; wireguard is
           | much faster.
        
         | binkHN wrote:
         | I've been doing this for many years now--happiness is not
         | keeping one or more beasts of machines in my backpack--and I
         | still do this over SSH tunnels (maybe I should finally migrate
         | to the WireGuard hotness).
        
         | systemvoltage wrote:
         | All this is fine and dandy if you don't care about keyboard
         | latency and writing code. If you're running a large workload,
         | this is the way to go. However, using a VM to write code is
         | just painful.
        
           | seabrookmx wrote:
           | Try the VSCode remote SSH extension. You'll often forget that
           | you're actually editing on a remote machine.
           | 
           | The interactive debugger works and everything.
        
           | kube-system wrote:
           | I don't write the code in a VM, I just run the code in a VM.
           | It depends on your development stack, but many stacks have
           | options for running code on remote machines. For example, you
           | can configure a Docker context running on another machine.
           | docker context create remote --docker
           | "host=ssh://user@remotemachine"
        
             | systemvoltage wrote:
             | Yes, PyCharm also has remote options.
             | 
             | But I see a lot of people writing code on remote machines.
             | A good keyboard + baremetal FreeBSD (no GUI) machine is an
             | absolute pleasure to write code on.
        
               | cyberpunk wrote:
               | At 80x25 or are you doing some 'mad tricks' with your
               | kernconf to get it higher res?
               | 
               | Got a diff on /usr/src/sys/amd64/conf/GENERIC (or
               | whatever you call yours)?
        
           | cyberpunk wrote:
           | mosh + tmux makes this largely a non-issue.
           | 
           | (source: I've spent the last 5 years working primarily on a
           | physical server in a proper dc and just connecting into it
           | from thin/fanless laptops)
        
         | colordrops wrote:
         | What's your recommended wireguard setup?
        
           | CharlesW wrote:
           | As a happy user, I can highly recommend trying Tailscale.
           | https://tailscale.com/kb/1086/tailscale-vs-wireguard/
        
           | kube-system wrote:
           | Vanilla WireGuard is not hard to use at all, it's by far the
           | easiest to configure VPN software.
           | 
           | Some routers have it built in, and some have packages to
           | install it, and the official GUI clients work well:
           | https://www.wireguard.com/install/
           | 
           | If you can't run it on your router, you can just set it up on
           | a linux VM and forward a port as necessary.
           | 
           | The configuration file is quite simple once you get the hang
           | of it, you've basically just got:
           | 
           | 1. a public/private key that you exchange between connected
           | machines
           | 
           | 2. the address of the tunnel, locally
           | 
           | 3. the address/port to get to the other end
           | 
           | 4. what traffic you want to send over the tunnel
        
             | viraptor wrote:
             | ZeroTier is even easier. 1. Install the package, 2.
             | zerotier-cli join (your network id), 3. Flip the new node
             | state to enabled in the control panel. No other config need
             | unless you want specific network config/filters.
        
             | daemoens wrote:
             | An easier method is to just use PiVPN https://www.pivpn.io.
             | It's much faster to setup and easier to manage with
             | extremely simple commands.
        
               | kube-system wrote:
               | I've looked at PiVPN, but it looks like _more_ work than
               | many of the packages available for routers. e.g. dd-wrt,
               | pfsense, opnsense all have point-and-click configuration
               | pages.
        
               | artificialLimbs wrote:
               | I'm not sure how this is possible. With pivpn:
               | 
               | install pivpn, open router port & forward (automatically
               | configured and optionally changed during setup), type
               | 'pivpn add' at the command line for every device I want.
               | Copy the outputted config files to device and import into
               | wg client. Done.
        
           | 1MachineElf wrote:
           | You might want to look into Tailscale if you're just starting
           | out. Configure a small VM to act as a Tailscale subnet router
           | for whatever network your macOS VMs are on, after which you
           | will be ready to access them remotely from the coffee shop.
           | If you prefer to have access to ESXi from a separate
           | VLAN/network, then get the Pro plan and setup a 2nd subnet
           | router for your hypervisor, NAS, etc.
        
           | artificialLimbs wrote:
           | 1.) Install wireguard.
           | 
           | 2.) Install pivpn.
           | 
           | 3.) (Optional) Modify makeCONF.sh/removeCONF.sh if needed.
        
       | dzhiurgis wrote:
       | Is there anything like this, but for docker (compose)?
        
         | viraptor wrote:
         | Not sure I understand the question, but you can point your
         | docker socket configuration at an external machine of any
         | architecture. That means you can run compose locally and it
         | build/runs remotely.
        
       | buildbuildbuild wrote:
       | Proxmox is great for this as well, minus VMWare's optimized "VNC"
       | compression and ability to pass through hardware devices.
        
         | evol262 wrote:
         | I've never used it, but I guarantee that Proxmox can pass
         | through PCIe devices with VFIO, and USB requires no hardware
         | support at all.
         | 
         | vmkernel hardware passthrough has exactly the same requirements
         | (IOMMU support).
        
         | digitallyfree wrote:
         | Proxmox has SPICE which is what I use for VDI instances on my
         | server - it's not as good as native but much better than VNC
         | (in my eyes it performs similarly to RDP and is not as fast as
         | Citrix or Horizon). I don't think it supports Mac guests
         | though, only Windows and Linux.
        
       | amelius wrote:
       | Why is Apple virtualizing Intel, but is Intel not virtualizing
       | Apple hardware?
        
         | gruez wrote:
         | Intel is incumbent, so most software (short of ios/android
         | apps) are already written/complied for x86. Because of this,
         | there's no real need for intel/amd to support ARM.
        
         | smoldesu wrote:
         | 1. Smaller companies like Corellium have already tried making
         | that mistake, and Apple sends their lawyer death squads to
         | their doorstep every time they try pushing a new feature.
         | 
         | 2. There aren't really any killer apps for ARM yet. ARM itself
         | is a fine ISA, but the majority of consumer desktop software
         | and server software is still x86 first (particularly on
         | platforms that Intel sells for). Until that changes, I doubt
         | Intel will really care all that much. When it _does_ change, I
         | 'm inclined to believe that the rest of the industry will be
         | eyeing even _more_ minimal ISAs like RISC-V. That 's mostly
         | just speculation though.
        
         | kmeisthax wrote:
         | Well, first off, Apple isn't virtualizing Intel, they're
         | emulating it. "Virtualization" implies that your CPU has
         | special hardware support for running a kernel as if it were a
         | regular OS process; which almost never crosses architecture
         | boundaries. Apple _does_ have special support in M1 for certain
         | x86 features like total store order, but most of the work is
         | done in software to translate binaries to ARM64 before they are
         | executed. They just omitted emulating anything beyond Intel
         | macOS user-mode, because that 's relatively easy and
         | lightweight[0].
         | 
         | Intel doesn't virtualize Apple hardware because it doesn't make
         | business sense and is questionably legal (see also: Corellium).
         | Apple silicon is _just-different-enough_ from a regular ARM64
         | design that anything that can actually boot macOS almost
         | certainly exists purely to break the macOS license agreement.
         | 
         | [0] Specifically, having all your code neatly packaged into
         | executables and libraries means that you can AOT-compile nearly
         | everything and not have to actually interpret or JIT x86 code.
         | There's also no need to emulate, say, x86 context switches or
         | page table walking; you just stop emulation, run the syscall on
         | the ARM side, and then restart the emulation once that's done.
         | 
         | Of course, they still _have_ a JIT, just in case you decide to
         | run a binary that also contains a JIT.
        
           | jsjohnst wrote:
           | > They just omitted emulating anything beyond Intel macOS
           | user-mode, because that's relatively easy and lightweight
           | 
           | Is it that? I would've assumed it's because the patents
           | hadn't expired yet.
        
       | Spooky23 wrote:
       | I switched to a "physicalization" model a long time ago.
       | 
       | It's hard to scale in a bigger company, but it just makes more
       | sense to me to segment the user experience layer from the random
       | compute layer.
       | 
       | I run a dozen servers for a little hobby project that has a few
       | customers. One unexpected cool way this has benefited me is I
       | eliminated the need to lug a laptop anywhere. I have a little
       | tools environment setup in iSH on my iPhone and can quickly
       | troubleshoot most things or perform various tasks on the command
       | line. A few others that haven't been scripted yet I can run by
       | SSHing in.
        
       | Melatonic wrote:
       | Surprised this is so new to people - ESXi has been free for years
       | and is the basis for every VMware setup out there. People have
       | been virtualizing MacOS since it was called OSX :-)
       | 
       | Using VMware Fusion in this way does sound useful in that it sort
       | of replicates the experience you get with vSphere (for managing
       | the VM's) which is really only something corporate clients would
       | be using and is definitely not free.
       | 
       | That being said you could really do this with almost any
       | hypervisor running on a machine at home (or in the cloud, or
       | anywhere) and then connect and control those VM's from a laptop
       | with internet. RDP, VNC, Teamviewer, Citrix, Horizon, whatever -
       | it is just basically us coming full circle back to the dumb
       | Terminal to Mainframe connection but over the internet.
        
         | irq wrote:
         | > Surprised this is so new to people - ESXi has been free for
         | years
         | 
         | > Using VMware Fusion in this way does sound useful in that it
         | sort of replicates the experience you get with vSphere
         | 
         | VMware's first big product, long before ESX (and later ESXi),
         | was VMware Workstation, released in 1999, which provided x86
         | virtualization and ran on (and virtualized) both Windows and
         | Linux. It was the first commercial product to easily enable
         | people to run Windows without having to leave their Linux
         | environment. VMware Fusion is essentially the same product,
         | just the spiritual successor to that product that runs on macOS
         | (along with a bunch of modern optimizations, of course) going
         | back to 1999.
        
       | F147H34D wrote:
       | I had an intel MacBook that was a good fit for doing reverse
       | engineering work on malware. I suppose this method would be kind
       | of a compromise for those that still want to use Mac system, even
       | know it is incompatible with most of their RE tools/virtual
       | machines.
       | 
       | Anyone used Ghirda on a M1 Mac?
        
         | angulardragon03 wrote:
         | Plenty of anecdotal evidence to suggest Ghidra works fine on
         | Apple Silicon (I also haven't personally run up against
         | anything unexpected)
        
         | saagarjha wrote:
         | I've been using Ghidra on Apple silicon even before M1 came
         | out, it works quite well. I'd suggest building it yourself so
         | you can get native decompilers, though.
        
       ___________________________________________________________________
       (page generated 2022-03-28 23:00 UTC)