[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-users
Subject:    Re: [qubes-users] Re: Qubes 3 MacOSX
From:       john.appleseed007 () gmail ! com
Date:       2015-09-29 1:35:58
Message-ID: f9596e54-7ccf-4ae0-9e90-e4dd6edd2ce6 () googlegroups ! com
[Download RAW message or body]


On Monday, September 21, 2015 at 2:44:32 AM UTC+10, Eric Shelton wrote:
> On Saturday, September 5, 2015 at 4:59:31 PM UTC-4, Eric Shelton wrote:On Monday, \
> August 31, 2015 at 8:27:21 AM UTC-4, Eric Shelton wrote:On Monday, August 31, 2015 \
> at 7:18:03 AM UTC-4, Marek Marczykowski-Górecki wrote:-----BEGIN PGP SIGNED \
> MESSAGE----- 
> Hash: SHA256
> 
> 
> 
> On Sun, Aug 30, 2015 at 06:17:30PM -0700, Eric Shelton wrote:
> 
> > On Tuesday, August 11, 2015 at 8:47:08 PM UTC-4, Eric Shelton wrote:
> 
> > > 
> 
> > > 
> 
> > > A patch to the Xen hypervisor is required to get past the CPU fault.   The 
> 
> > > patch adds support for an undocumented MSR 0x35, which the OS X kernel 
> 
> > > makes use of to determine the number of cores, etc.   Xen's default behavior 
> 
> > > is to return zero for this MSR, which eventually segfaults the kernel.
> 
> > > 
> 
> > > A second patch to the hypervisor is required if your computer is running a 
> 
> > > Haswell (or above?) CPU, to get OS X to work with Xen's TSC emulation. 
> 
> > > Basically, the patch emulates/implements a few of VMware's CPUID 
> 
> > > hypervisor leaves.   Without this patch, OS X will manage to boot up, but 
> 
> > > not for long.
> 
> > > 
> 
> > 
> 
> > There was a mistake in the previously posted patch, plus it was incomplete, 
> 
> > so I deleted my previous post.   With the attached patch, using the attached 
> 
> > appvm config file, it is possible to boot up an OS X 10.9 installer using 
> 
> > the Chameleon bootloader on a Haswell system.   However, the mouse will not 
> 
> > work - OS X does not like the USB tablet used by Qubes.   Further work is 
> 
> > required to get things to where OS X can be installed and used.   However, 
> 
> > the patch gets you past the crashes you would experience with the stock Xen 
> 
> > hypervisor.
> 
> 
> 
> Is the patch going to the upstream Xen? Or maybe its even already there
> 
> and here it is a backport? I think it worth trying to get it included
> 
> there.
> 
> 
> 
> 
> Although I supplied it as a single patch, there are three parts, each with a \
> different status: 
> 
> 1) Add MSR 0x35.   I tried upstreaming this about a year ago, but the Xen team was \
> unwilling at that time to add an MSR that apparently is not officially documented \
> by Intel.   I have a request for info outstanding with some kind folks at Intel, \
> but nothing has come up yet. 
> 
> 2) Add VMware CPUID leaf 0x40000010.   The same thing is included as part of Don \
> Slutz's patches for adding VMware tools support.   It looks like those patches are \
> done or nearly done, but he just barely missed the feature freeze for Xen 4.6. 
> 
> 3) Report correct number of CPUs in CPUID leaves 1 and 4.   I had previously been \
> doing this by overriding the CPUID values via an xl.cfg file.   Since this was no \
> longer an option under libvirt, I did the same thing directly in the hypervisor.   \
> I will try upstreaming after Xen 4.6 release activities settle down.   Hopefully \
> the change will be acceptable, although I am guessing there may be some issue with \
> hotplugging CPUs that led to these leaves reporting 32 CPUs in the first place. 
> 
> The difficulty with getting items 1 and 3 upstreamed is that only OS X appears to \
> rely on these, or at least to an extent that OS X will crash if they are not \
> consistent with the number of VCPUs.   The perspective of the Xen team generally \
> seems to be that the OS X kernel is acting in a nonstandard manner (such as using \
> an undocumented MSR), and that the Xen hypervisor should not be modified to \
> accommodate OS X's quirks. 
> 
> After some more work, I can now report that I have successfully installed and run \
> OS X 10.10.5 (the latest non-beta version) in an HVM stubdom.   I have attached the \
> files I used to get Qubes to get it to work.   The hardest part will be stage 1 \
> below, as it requires you to rebuild the Xen hypervisor and install the updated \
> RPMs in dom0.   At this moment, I am not going to go into all of the details \
> required to do that, as I would rather document the things specific to getting OS X \
> to get up and running happily.   Please note this was done on a Haswell system - I \
> do not know if more recent processors will present a new host of issues, like \
> Haswell did over previous generations. 
> 
> Stage 1 -   rebuild the Xen hypervisor to allow Darwin kernel to boot and improve \
> RTL 8139 emulation: 
> 
> 1. Set up an appvm for building Qubes R3.   \
> https://www.qubes-os.org/doc/QubesR3Building/ is likely to be of some help. 
> 
> 2. In the configured qubes-builder directory, run 'make get-sources'
> 
> 
> 3. Copy the attached two .patch files to qubes-src/vmm-xen/patches.misc
> 
> 
> 4. Add the following two lines to qubes-src/vmm-xen/series.conf"
> patches.misc/xen-osx.patch
> patches.misc/qemu-rtl8139-backports.patch
> 
> 
> 5. Run 'make vmm-xen'.   This will take a little while
> 
> 
> 6. Copy the following two files to dom0 (see  \
> https://www.qubes-os.org/doc/CopyToDomZero/): \
> qubes-src/vmm-xen/pkgs/fc20/x86_64/xen-hvm-4.4.2gui3.0.0-6.fc20.x86_64.rpm 
> qubes-src/vmm-xen/pkgs/fc20/x86_64/xen-hypervisor-4.4.2-6.fc20.x86_64.rpm
> 
> 
> 
> 7. In dom0, run 'sudo yum reinstall ./xen-h*rpm' wherever you copied the above RPMs \
> into dom0. 
> 
> 8.   Reboot.   On to stage 2.
> 
> 
> Stage 2 - installing OS X into an appvm:
> 
> 
> 1. Set up a USB drive to install OS X (at least 8GB stick).   There are many ways \
> to go about this.   However, you have to use a Hackintosh-style method, because, if \
> nothing else, a Qubes HVM domain does not do EFI boot (which stock OS X requires).  \
> What worked for me is shown at  \
> http://www.tonymacx86.com/yosemite-desktop-guides/143976-unibeast-install-os-x-yosemite-any-supported-intel-based-pc.html \
> This is easy enough to do on a Mac that you have set up to dual boot Qubes and OS \
> X. 
> 
> 2. There are several kexts that are required for OS X to boot with the virtual \
> devices provided by QEMU.   If you used the UniBeast method above, or any other \
> Chameleon-based approach, you copy the kexts into the /Extra/Extensions folder on \
> the USB drive.   The kexts you need to track down are: AppleIntelPIIXATA2.kext \
> (very, VERY important) PCGenRTL8139Ethernet.kext (version 1.4.1 is available \
> somewhere) FakeSMC.kext
> NullCPUPowerManagement.kext
> 
> 
> Other kexts I had, but may not be needed, are:
> AppleACPIPS2Nub.kext
> AppleACPIPlatform.kext
> ApplePS2Controller.kext
> EvOreboot.kext
> 
> 
> 3.   Copy the following onto the USB as well, as this gets the mouse working at the \
> end of everything: http://philjordan.eu/osx-virt/binaries/QemuUSBTablet-1.1.pkg \
> (found via  http://philjordan.eu/osx-virt/) 
> 
> 
> 4.   Using Qubes Manager, create an HVM-based appvm (no less than 20 GB disk \
> space).   The examples and attachments assume the appvm is named 'osx'.   They also \
> assume your USB stick comes up as /dev/sdb.   You will need to update them to match \
> anything different about these on your system. 
> 
> 5.   Copy the other two attachments (osx-upstream.cfg and myosx.conf) into \
> /var/lib/qubes/appvms/osx.   Revise them as noted above, if needed.   One of the \
> revisions might include providing less than 4GB of memory.   Update the attached \
> files with the MAC address and IP address assigned to your appvm. 
> 
> 6.   QEMU upstream has to be used for the initial phases of the install, as that is \
> the only way to get the mouse to work.   To do this, in /var/lib/qubes/appvms/osx, \
> repeatedly run 'sudo xl set-mem dom0 1500' and 'sudo xl -vvv create \
> osx-upstream.cfg' until the HVM domain starts up.   You may have to modify the 1500 \
> value and the amount of memory assigned in osx-upstream.cfg toi work with the \
> amount of memory available of your system.   You probably can dial the memory in \
> osx-upstream.cfg down to 2048, I would guess. 
> 
> 7.   When the HVM window pops up, IMMEDIATELY hit F12 (you won't have much time).   \
> Choose the USB drive (in the attached .cfg file, this would be drive 2).   Assuming \
> you are doing the above UniBeast method, you then simply choose to boot from the \
> USB drive.   It may take a few minutes, but you should end up at the OS X \
> installer.   If it fails before it gets there, you should add '-v -f debug=0x14c' \
> to the Darwin boot arguments (for Chameleon, see the file \
> /Extra/org.chameleon.Boot.plist, and put this into the value for "Kernel Flags"; \
> while there, you might also set "Graphics Mode" to "1440x900x24" or such).   The \
> 'debug=0x14c' portion gets the OS X kernel to log output via the serial port, which \
> you can review in /var/log/xen/console/guest-osx-dm.log 
> 
> 8.   Install OS X to the virtual hard drive.   Reboot.
> 
> 
> 9.   Do the   'sudo xl set-mem dom0 1500' and 'sudo xl -vvv create \
> osx-upstream.cfg'  thing to bring up OS X again.   This time, tell Chameleon to \
> boot from the hard drive, instead of the install USB.   You will then run through \
> the final part of the OS X installer.   When it asked you about the network \
> adapter, choose manual config, and input the values for the appvm.   It will not \
> find the network, because there is no network in qemu-upstream, but this gets it \
> ready for running in the stubdom HVM. 
> 
> 10.   Once OS X finished coming up, run QemuUSBTablet-1.1.pkg you copied to the USB \
> drive.   This installs the necessary driver for the mouse in the stubdom.   Shut \
> down OS X - we should never need to go back to qemu-upstream now. 
> 
> 11.   Run 'qvm-run osx --custom-config myosx.conf'   Use Chameleon on the USB stick \
> to boot into the hard drive again.   Everything should now work.   The display is \
> going to be a little sluggish, given that QEMU provides an emulated SVGA adapter, \
> and OSX is tailored to running in a full-blown GPU.   You probably want to \
> investigate how to take the USB stick out of the loop by installing Chameleon to \
> your virtual hard drive.   The above link for setting up the install USB talks \
> about using a program called Multibeast to do this.   There are other methods. 
> 
> There are some quirks with the mouse support - not everything seems to register \
> single clicks quite right or with a single click.   A workaround for this is to use \
> OS X's built-in VNC support, under System Preferences->Sharing->Screen Sharing.   \
> Note that getting the OS X appvm network to communicate with another appvm running \
> vncviewer has its own set of hoops to jump through (see the section "Enabling \
> networking between two AppVMs" at  https://www.qubes-os.org/doc/QubesFirewall/) 
> 
> The above steps are not simple, but I can say that they worked for me.   If \
> something doesn't work, you will probably have to roll up your sleeves and exercise \
> your Google search-fu to identify a solution.   Some additional steps are likely \
> needed to get all of the OS X features running (there is a fair chance the App \
> Store will not work without certain SMBIOS values being provided).   Some programs \
> may never work under QEMU (the maps program does not seem to).   An OS X appvm may \
> be a good candidate for GPU passthrough, although I have not heard any reports on \
> this. 
> 
> Best of luck for those who wish to go down this road...
> 
> 
> Eric
> 
> 
> As an update, I have had some success lately getting the El Capitan GM Candidate \
> running using the following bootloader: 
> 
> http://www.insanelymac.com/forum/topic/306960-chameleon-os-x-el-capitan/
> 
> 
> 
> I just used the default config, using the desktop SMBIOS.   The only extensions you \
> need to add top /Extra/Extensions are AppleIntelPIIXATA2.kext and \
> PCGenRTL8139Ethernet.kext.   For kernel boot arguments (see \
> /Extra/org.chameleon.Boot.plist is the USB stick you create), I used "-v -f \
> debug=0x14c maxmem=4096 darkwake=0 dart=0 PCIRootUID=1" (adjust maxmem according to \
> your setup).   This should get the installer up and running.   On subsequent boots \
> from the OS drive, I have found the "Boot Ignore Caches" option necessary. 
> 
> Also, the QEMU tablet driver I noted above, which did not work very well with \
> Yosemite, does not work at all with EL Capitan.   Instead, you should use the \
> driver available from here, which appears to work almost perfectly (with exception \
> of goofiness with dragging on 1.0 driver pkg): 
> 
> https://github.com/SipRadius/Qemu-USB-Tablet-Driver
> 
> http://www.chui-pas.net/qemu/Qemu-Tablet-Driver-v1.0.pkg (download package from \
> here - I don't think this has the drag fix, so dragging is a little unusual, and \
> does not work for everything). 
> 
> 
> Presumably, this will work just as well with the final release version at the end \
> of the month.   So now, Mac users can run Qubes, but not have to leave Qubes and do \
> dual boot to still run OS X. 
> 
> Eric

Hey Eric, are you running Qubes off a Mac? If so, which model?

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-users" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-users+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-users@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-users/f9596e54-7ccf-4ae0-9e90-e4dd6edd2ce6%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.



[prev in list] [next in list] [prev in thread] [next in thread]