VMs in ARM MBPs

[mick2]

With the speculative move to ARM processors mooted in the next couple of years, it occurred to me that this could have a significant effect on ones ability to use VMs on MBPs in the future. As most VMs I'm aware of (VirtualBox, VMWare, Parallels?) make use of hardware virtualisation technology directly inside the Intel chip, this would presumably be broken in any move to ARM.

What do people think will happen here in practice? Will Apple include some sort of compatibility layer inside their ARM chips to enable Intel virtualisation tech to work (seems unlikely to me - both technical & licensing issues abound here)? Will ARM include proprietary Apple VM tech of its own that will then be supported by the major VM vendors? Am curious what people for whom VMs are at the centre of their workflow are intending to do if/when the ARM move happens.

 

[Strelok]

These rumors are just that, rumors. I wouldn’t expect it any time soon. I would expect there to be VM capabilities in the chips if it were to happen though.

 

[maflynn]

What do people think will happen here in practice? Will Apple include some sort of compatibility layer inside their ARM chips to enable Intel virtualisation tech

The only option is emulation which will be dog slow. The virtualization technology in intel chips virtualizes the chip, so all of the instructions, registers and what not are accessible, where as ARM uses a completely different architecture there's no way you can run an Intel virtual environment.

Back in the day, when apple was on the PPC platform, there was no way to run windows other then emulation and the performance was horrible, only the most dedicated or most critical needs made sense.

 

[mick2]

The only option is emulation which will be dog slow. The virtualization technology in intel chips virtualizes the chip, so all of the instructions, registers and what not are accessible, where as ARM uses a completely different architecture there's no way you can run an Intel virtual environment.

Back in the day, when apple was on the PPC platform, there was no way to run windows other then emulation and the performance was horrible, only the most dedicated or most critical needs made sense.

I hear you re s/w emulation. Too slow and often not 100% compatibility. But unless Apple do something here, they'd risk instantly losing a huge proportion of their dev userbase, many of whom use VMs in almost every workflow.
Thinking about the IT world in a wider context, the trend for containers / VMs and other lightweight virtualisation technologies is only increasing - witness WSL2 in Win10, Docker, Kuvbernetes on servers etc. I just can't imagine Apple moving to ARM without implementing some sort of solution here. An Apple written ARM VM server available as an app for MacOS maybe?? Will await the news that Apple has suddenly bought out Parallels with baited breath...

 

[Stephen.R]

This is one of the reasons I'm pretty confident the rumoured "ARM Mac" is just an extension of the current scenario with T2 chips: more low-level functionality is handed off to one or more of Apple's Axx series chips (or derivatives thereof) operating as a co-processor, while the main processor remains an Intel mainstream chip.

 

[jerryk]

So what sort of VMs are people using with their MBPs and what sort of applications are they running? I have Parallels installed, but am thinking about deinstalling it and not paying for the licenses. With the low price of Windows laptops can cheaply get a dedicated machine for my Windows development work. Also, I am finding more and more of my work is done in the cloud.

 

[leman]

The only option is emulation which will be dog slow. The virtualization technology in intel chips virtualizes the chip, so all of the instructions, registers and what not are accessible, where as ARM uses a completely different architecture there's no way you can run an Intel virtual environment.

That is not the only option. Apple could recompile x86 machine code to ARM — they have the technology for that. Sure, this would require some hardware support from the CPU (as some SIMD instructions etc. are difficult to map), but it's doable.

 

[mick2]

So what sort of VMs are people using with their MBPs and what sort of applications are they running? I have Parallels installed, but am thinking about deinstalling it and not paying for the licenses. With the low price of Windows laptops can cheaply get a dedicated machine for my Windows development work. Also, I am finding more and more of my work is done in the cloud.

Web devs I know have LAMP stacks running in a local VM - fast deployment to a test environment and VMs with various OSs for checking browser issues across platforms. VMs are also good for those in security for spinning up safe test environments; some data scientists use them for spinning up repeatable, consistent configured environments for specific runs.

I'm running fedora now and have several QEMU VMs running various flavours of Win (XP / 7 / win10) in order to continue to support, bugfix and develop old business-critical apps I wrote years ago.

Many open source dev frameworks like Ruby, Python that ship with MacOS are either absent or are long deprecated versions; I used a VMWare VM running Linux on my MBP to learn and run modern versions of these frameworks in.

Am sure there are other uses too.

 

[maflynn]

That is not the only option. Apple could recompile x86 machine code to ARM — they have the technology for that. Sure, this would require some hardware support from the CPU (as some SIMD instructions etc. are difficult to map), but it's doable.

You're really reaching on this, yes technically they could reverse engineer the machine code (and taking time to avoid intel's IP) and bake that into their ARM chips, but that just doesn't seem feasible.

 

[mick2]

That is not the only option. Apple could recompile x86 machine code to ARM — they have the technology for that. Sure, this would require some hardware support from the CPU (as some SIMD instructions etc. are difficult to map), but it's doable.

This is the kind of area I'm wondering about but can't quite conceive it...are you talking about some kind of layer in hardware that would offer an x86 binary interface to an app and translate it into native ARM machine code?? Is this even possible?

 

[pshufd]

Emulation, Translation and JIT compilation are the modern options.

Back in the 1990s, Digital Equipment Corporation (bought out by Hewlett-Packard) had software called FX!32. This ran on the Alpha chip and it provided emulation and translation services for Windows NT so that Windows NT and programs could run on Alpha systems. You could start up translation of programs on demand or schedule it at night. It was mostly like running Windows and Windows applications normally.

It worked for about 90% of applications. The problem is where there was assembler or machine code used in an application and this could be hard to translate as it would depend on instruction sizes and those could change in translation.

There are some other architectural issues like Intel Optane and I'd guess that there are some instructions that would just be really hard to do. The SIMD instructions, particularly support for 512-bit vectors, might be difficult for atomic operations if ARM doesn't have that natural datatype.

 

[leman]

You're really reaching on this, yes technically they could reverse engineer the machine code (and taking time to avoid intel's IP) and bake that into their ARM chips, but that just doesn't seem feasible.

What do you want to reverse engineer? The x86 is a well-documented architecture. And Apple would not need to implement any of x86 in hardware (see below). Intel IP is a different issue, but its a legal minefield. if Apple did what I suggest they would not be actually running x86 code, they would be translating this code into something else. Does this violate Intel IP? No idea.

This is the kind of area I'm wondering about but can't quite conceive it...are you talking about some kind of layer in hardware that would offer an x86 binary interface to an app and translate it into native ARM machine code?? Is this even possible?

No, what I am saying is that machine code is just a programming language, albeit not a very human-friendly one. And you can write a compiler that translates from one kind of machine code to another one. In this approach, Apple would be taking a x86 binary image and compiling the instructions contained there to a different kind of machine code. The interesting thing is that basic data types and alignments are absolutely identical between x86-64 and 64-bit ARM, so its technically possible. The biggest issue I see is avoiding performance hits when translating some instructions that do not have direct equivalents.

In reality, Intel CPUs also don't run on x86 binary either — the "real" instructions are very different. Intel CPUs have an instruction decoder that reads in the x86 binary and translates them into the instructions that the CPU can really understand.

 

[jerryk]

Emulation, Translation and JIT compilation are the modern options.

Back in the 1990s, Digital Equipment Corporation (bought out by Hewlett-Packard) had software called FX!32. This ran on the Alpha chip and it provided emulation and translation services for Windows NT so that Windows NT and programs could run on Alpha systems. You could start up translation of programs on demand or schedule it at night. It was mostly like running Windows and Windows applications normally.

It worked for about 90% of applications. The problem is where there was assembler or machine code used in an application and this could be hard to translate as it would depend on instruction sizes and those could change in translation.

There are some other architectural issues like Intel Optane and I'd guess that there are some instructions that would just be really hard to do. The SIMD instructions, particularly support for 512-bit vectors, might be difficult for atomic operations if ARM doesn't have that natural datatype.

Alpha and Windows NT were tightly linked from the beginning. Dave Cutler worked on the Alpha at DEC in Seattle (at DEC-wet) and went to Microsoft to run the Windows NT team. Use next letters from VMS and you get WNT (Windows NT).

 

[pshufd]

What do you want to reverse engineer? The x86 is a well-documented architecture. And Apple would not need to implement any of x86 in hardware (see below). Intel IP is a different issue, but its a legal minefield. if Apple did what I suggest they would not be actually running x86 code, they would be translating this code into something else. Does this violate Intel IP? No idea.

No, what I am saying is that machine code is just a programming language, albeit not a very human-friendly one. And you can write a compiler that translates from one kind of machine code to another one. In this approach, Apple would be taking a x86 binary image and compiling the instructions contained there to a different kind of machine code. The interesting thing is that basic data types and alignments are absolutely identical between x86-64 and 64-bit ARM, so its technically possible. The biggest issue I see is avoiding performance hits when translating some instructions that do not have direct equivalents.

In reality, Intel CPUs also don't run on x86 binary either — the "real" instructions are very different. Intel CPUs have an instruction decoder that reads in the x86 binary and translates them into the instructions that the CPU can really understand.

CSDL | IEEE Computer Society

www.computer.org

[automerge]1570641858[/automerge]

Alpha and Windows NT were tightly linked from the beginning. Dave Cutler worked on the Alpha at DEC in Seattle (at DEC-wet) and went to Microsoft to run the Windows NT team. Use next letters from VMS and you get WNT (Windows NT).

I'm familiar with the DEC copyright headers in WNT Source files and the deal around 2000. I received one of the emails from Cutler on the Windows news.

You could do translations but there are some areas where it wouldn't work. You could use emulation for those areas.

One of the projects I worked on used a significant amount of generated code and likely wouldn't work with binary translation.

 

[mick2]

No, what I am saying is that machine code is just a programming language, albeit not a very human-friendly one. And you can write a compiler that translates from one kind of machine code to another one. In this approach, Apple would be taking a x86 binary image and compiling the instructions contained there to a different kind of machine code.

Ok you're talking about recompiling s/w for a different architecture. And this is indeed what app developers will need to do if/when Apple move to ARM. But the VM issue is more difficult; VM software hooks into native CPU instructions in the Intel CPU in order to do its thing. Obviously these instructions won't be present on an ARM chip. You could quite possibly recompile, say, VMWare (the 'app') to run under ARM; but that still wouldn't give you the hardware-level x86 instruction set that, say Win10, running in the VM would expect to see.

 

[pshufd]

Ok you're talking about recompiling s/w for a different architecture. And this is indeed what app developers will need to do if/when Apple move to ARM. But the VM issue is more difficult; VM software hooks into native CPU instructions in the Intel CPU in order to do its thing. Obviously these instructions won't be present on an ARM chip. You could quite possibly recompile, say, VMWare (the 'app') to run under ARM; but that still wouldn't give you the hardware-level x86 instruction set that, say Win10, running in the VM would expect to see.

He's talking about machine code translation. App developers will just specify a different target for compiling and linking.

One of the problems with machine code translation is that the "language" isn't necessarily deterministic. Traditional languages are designed so that what a piece of code does is well-defined. Machine-code wasn't designed as a language to do that.

 

[maflynn]

What do you want to reverse engineer? The x86 is a well-documented architecture

Intel no doubt has its chipsets and x86 machine code patented and/or copyrighted. If apple blatantly copies its machine code, they'll be getting sued.

they would be translating this code into something else. Does this violate Intel IP? No idea.

So you're saying they should build an emulation then - kind of what I said

 

[pshufd]

Intel no doubt has its chipsets and x86 machine code patented and/or copyrighted. If apple blatantly copies its machine code, they'll be getting sued.

So you're saying they should build an emulation then - kind of what I said

What do you mean by "copies its machine code"?

Apple wouldn't be copying anything. They would be translating machine code from one architecture to another.

 

[mick2]

He's talking about machine code translation. App developers will just specify a different target for compiling and linking.

One of the problems with machine code translation is that the "language" isn't necessarily deterministic. Traditional languages are designed so that what a piece of code does is well-defined. Machine-code wasn't designed as a language to do that.

Ok 'machine code translation': in abstract terms, this is a layer that sits between the ARM VM environment and the hosted OS then? And it translates low level CPU specific machine code between the 2 architectures? This presumably done on the fly / JIT, in software? Again, just trying to conceptualise how this could be implemented. If as I've speculated above it sounds like we're back to MAFlynn's observation about emulation & slowness (& possibly a lack of 100% compatibility)?

 

[pshufd]

Ok 'machine code translation': in abstract terms, this is a layer that sits between the ARM VM environment and the hosted OS then? And it translates low level CPU specific machine code between the 2 architectures? This presumably done on the fly / JIT, in software? Again, just trying to conceptualise how this could be implemented. If as I've speculated above it sounds like we're back to MAFlynn's observation about slowness (& possibly a lack of 100% compatibility)?

Machine Code translation of an application would run natively on the host. That gets rid of the requirement to run a VM.

 

[johannnn]

But unless Apple do something here, they'd risk instantly losing a huge proportion of their dev userbase, many of whom use VMs in almost every workflow.

It's not like all Apple computers will go ARM overnight.

Many people used CD-drives when MBA was released in 2008, but that didn't result in losing the huge proportion of users that needed CD-drives.

 

[mick2]

It's not like all Apple computers will go ARM overnight.

Many people used CD-drives when MBA was released in 2008, but that didn't result in losing the huge proportion of users that needed CD-drives.

Sure, existing non-ARM machines would continue to exist and be used, but from that point on the entire focus of MacOS and app developers' efforts would be on ARM, not x86. As owners of the last generation of PowerPCs discovered, their days became numbered rather quickly. In terms of VMs, would VMWare / Parallels etc continue to keep their MacOS apps updated & secure for what would be an abandoned architecture on the Mac?

 

[leman]

Intel no doubt has its chipsets and x86 machine code patented and/or copyrighted. If apple blatantly copies its machine code, they'll be getting sued.

I have written x86 machine code. Does this mean that Intel can sue me? Any open-source compiler out there uses and generates machine code. I don't see Intel suing them either.

So you're saying they should build an emulation then - kind of what I said

How would you define emulation? When one says emulation one usually means interpretation: you maintain a software model of the target machine and "run" the code by having your program interpret how the individual instructions modify that model.

What I am talking about is translation. You take the x86 machine code and produce ARM code out of it that would have the same effect when run. Does this violate Intel patents? I have honestly no idea...
[automerge]1570644747[/automerge]

Ok 'machine code translation': in abstract terms, this is a layer that sits between the ARM VM environment and the hosted OS then? And it translates low level CPU specific machine code between the 2 architectures? This presumably done on the fly / JIT, in software? Again, just trying to conceptualise how this could be implemented.

For all intends and purposes, if done properly, the translator would take a x86 program and produce an ARM program that does exactly the same thing. Of course, using a VM would complicate the matters in a way that I can't predict
[automerge]1570644784[/automerge]

CSDL | IEEE Computer Society

www.computer.org

Yep, only nowadays one would use LLVM for this.

 

[Stephen.R]

So what sort of VMs are people using with their MBPs

My MBP isn’t my daily driver any more but generally I run anywhere from one to a dozen Linux VMs, occasionally a Windows VM to test something or a macOS High Sierra (I think?) VM for a billing/invoicing app.

It's not like all Apple computers will go ARM overnight.

Many people used CD-drives when MBA was released in 2008, but that didn't result in losing the huge proportion of users that needed CD-drives.

The migration away from optical drives is very different: for those that still need one, it’s a USB plug away. Apple still sells a USB optical drive in 2019.

 

[pshufd]

I use a Linux VM for development. A lot of my other tools have versions that run on Mac, either using Java or WINE (yuck!). The apps using Java have performance issues.