[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Xen and OS X.

  • To: xen-users@xxxxxxxxxxxxx
  • From: "Austin S. Hemmelgarn" <ahferroin7@xxxxxxxxx>
  • Date: Mon, 25 Jul 2016 15:39:36 -0400
  • Delivery-date: Mon, 25 Jul 2016 19:41:14 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

On 2016-07-25 10:40, Simon Hobson wrote:
George Dunlap <george.dunlap@xxxxxxxxxx> wrote:

More specifically, one of the things that makes Apple's life a lot
easier than Microsoft's is that they only need OS X to run on a small
handful of hardware platforms -- platforms which Apple controls.
Unlike Windows, which needs to run on any PC, or Linux, which runs on
just about everything on the planet, OS X assumes that it's running on
an Apple hardware platform and will simply fail if you try to boot it
on a platform that doesn't look like an Apple system.

You need to differentiate between two distinct aspects. AIUI :

1) One is hardware compatibility. Apple hardware isn't that special these days - and on 
the various forums etc you'll find information on what hardware is "supported" 
(as in, has drivers etc). In that respect, Xen isn't so different either - if you have a 
supported CPU and emulate supported devices (eg NICs) then that's half the battle.
As you say, this is the easy bit, QEMU can emulate all the hardware Darwin needs to run, and almost all that a full OS X system needs, so it's doable with a HVM domain on Xen (I've actually run Darwin (without OS X on top) in QEMU before, and while I've never tried it on Xen, I suspect it's not much more difficult).

2) The biggie is that there is code which explicitly checks for Apple hardware and deliberately 
stops the boot if it's "not genuine". So a big chunk of the Hackintosh task is in working 
around this code, and dependencies on it. It's not so much booting a "non-Apple but OS X 
like" kernel, but booting the real Apple OS X kernel, but working around the bits that are 
designed to break the system.
This is what usually gets people. I haven't looked recently at what all is involved, but I'm pretty certain there's multiple places that the OS directly executes bits of firmware to verify things, and that handshake is the really tough part. There's other stuff too though, if certain types of hardware present in ways OS X doesn't expect, it may refuse to boot also (although this is partly to protect against running on hardware that's actually broken).

In either case, you'd be in questionable legal waters with regard to
the license for Apple's software (or at least this used to be the
case), so take care.

Indeed. Though given how many forums/sites are still up after quite a long life, one has to suspect that 
Apple might be taking a slightly "pragmatic" approach to things. Yes, if you try and make money 
from it, they very publicly come down like the proverbial ton of bricks - but it does appear that they at 
least turn a bit of a blind eye to "personal use". That's just conjecture based on observation - 
perhaps they'd rather have those personal user on board and perhaps they'll get converted into 
"real" paying users over time ?
Which is an odd stance IMHO, because most people I know who use Hackintosh stuff do so because they don't want to spend the money on hardware that isn't end-user repairable and depreciates faster than other systems.

Then there's the grey areas. Parallels won't run OS X 10.6 as a VM - but there is a 
workaround which makes the system "look like" it's a server version (and then 
Parallels will run it). The difference is that the EULA for the server version permits 
virtualisation (on Apple hardware), the desktop version permits only running on Apple 
The big question is where the verification is. I'm pretty certain that there's mutual verification between the hypervisor and the OS in this case, it's just that the OS is more permissive (I'd be more than willing to bet that this is due to Apple using VM's internally for testing of the desktop version).
I've had people who really you would expect to know better argue that when you virtualise 
a system (in this case, with Parallels and hosted on Apple hardware), it's no longer 
running on the Apple hardware. So it's held in the same RAM, it executes on the same CPU, 
but it's no longer running on the Apple hardware ... that's an "interesting" 
The argument here as I understand it is that the firmware is different, thus it's not an Apple platform, and they technically are correct in that respect. It's running on the same _hardware_, but for an OS, the firmware is an integral part of the hardware these days, and a firmware update does mean you're not running on the same system (especially if you're using SecureBoot).

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.