Even if Apple's ARM chips are not classically virtualizable (and I don't know whether that is the case), that was indeed the case for the x86 (pre VT-x) when two fairly straightforward solutions were applied: binary translation of non-virtualizable instructions (VMware approach) and paravirtualization (Xen approach.) This sparked the x86 virtualization revolution even before hardware support was available from intel and AMD.
Other approaches that could potentially work on a "non-virtualizable" ARM CPU include user-mode Linux, emulation, microkernels (similar to paravirtualization - recall Xnu contains mach and presumably still has the ability to outsource system calls and paging) and containers.
Particularly the main piece of virtualization is an added level of indirection to the page table walking hardware.
There's some IOMMU stuff that can be bought off the shelf (and ARM's SMMU for this is really good actually), but I imagine Apple would build their own (or acquire it) looking at the rest of their IP blocks.
Edit: Actually I'm not even sure if they could pull an SMMU in. Do we have confirmation that they're using AXI/CHI or do they have something else for their NoC protocol?
Then virtualization will just occur in the touchbar using emojis as feedback. ;)
I'd imagine the most common scenario for that would be macOS guests running on ESXi on Mac hardware, but my understanding is that e.g. a macOS guest under say Vbox or KVM with a linux host OS should also be "ok" in terms of the EULA.
Has a single court of law yet made a ruling to set a precedent saying they are legally binding?
If no, I’ll just keep treating EULAs like what they are: a corporate wish list of unlawful restrictions they want to impose on their customers.
Why should anyone care about that?
Many of the use cases for virtualizing OSX are for business purposes. Not a great idea to build a business off pirated software and trampled software licenses.
At the very least: ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996).
Cool, why is this even posted?
$ cat /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
System/Library/Frameworks/Virtualization.framework/Headers/VZBootLoader.h
//
// VZBootLoader.h
// Virtualization
//
// Copyright © 2019 Apple Inc. All rights reserved.
//
#import <Virtualization/VZDefines.h>
NS_ASSUME_NONNULL_BEGIN
/*!
@abstract Base class of boot loader configuration.
@discussion
VZVirtualMachineConfiguration requires a boot loader defining how to start the virtual machine.
VZBootLoader is the abstract base class of boot loader definitions.
Don't instantiate VZBootLoader directly, instead you should use one of its subclasses.
@see VZLinuxBootLoader.
*/
VZ_EXPORT API_AVAILABLE(macos(11.0))
@interface VZBootLoader : NSObject <NSCopying>
+ (instancetype)new NS_UNAVAILABLE;
- (instancetype)init NS_UNAVAILABLE;
@end
NS_ASSUME_NONNULL_ENDIs that correct?
In early 1977, Unix V6 was an app that run on Interdata OS/32 [1]. (Within a few months, it had gained the ability to run directly on the Interdata 7/32 hardware, without the need for the rather primitive OS/32 operating system to sit under it.)
AT&T's 1979-1980 port of Unix to IBM mainframes ran it on top of the TSS/370 operating system [2]. (TSS was IBM's original, and ultimately unsuccessful, attempt to deliver timesharing for S/360 mainframes – TSO under MVS, and VM/CMS, succeeded where TSS largely failed. But TSS hung on for a few more years, sustained by the handful of customers using it, and AT&T decided it was the best base for their mainframe Unix port, and IBM was wiling to support them in that.)
[1] http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/...
[2] https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf
Just wish it was debian based
Otherwise they would be paying GNU/Linux OEMs.
We are still not sure about ASi’s memory map and if/how there are other limitations that might prevent it from booting anything other than macOS.
In the short term I expect that to be problematic. First party packages in the distro's package manager will be fine, but I expect it might be hard to find some third-party software compiled for ARM Linux. And any Docker containers in the Linux VM will need to use multi-arch or ARM Docker images.
Closed source, commercial software might be a bit more of a crapshoot, of course, but this should provide a fair bit of impetus.
I agree.
I liked that you could run docker on osx, but there was no support for something like FROM macosx:10.6
Maybe it will be possible? If apple put 1/1000th of the effort into virtualization/containers that they put into emojis...