qemu + haxm does not work to boot and run Mac OS X High Sierra

[Marietto2008]

Hello,

I tried to boot Mac Os X High Sierra with Qemu (3.1.0) and HAXM,but it did not work. Maybe someone can help me to fix it in some way ? Would be nice to make it work,since HAXM does not support nested virtualization...

C:\Programmi\qemu\qemu-system-x86_64 -m 3072 -cpu Penryn,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on -machine pc-q35-2.9 -smp 4,cores=2 -usb -device usb-kbd -device usb-tablet -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" -drive if=pflash,format=raw,readonly,file=C:\Programmi\qemu\OVMF_CODE.fd -drive if=pflash,format=raw,file=C:\Programmi\qemu\OVMF_VARS-1024x768.fd -smbios type=2 -device ich9-intel-hda -device hda-duplex -device ide-drive,bus=ide.2,drive=Clover -drive id=Clover,if=none,snapshot=on,format=qcow2,file=C:\Programmi\qemu\Clover.qcow2 -device ide-drive,bus=ide.1,drive=LinuxHDD -drive id=LinuxHDD,if=none,file=I:\OS\Images\mac_hdd.img,format=qcow2 -device ide-drive,bus=ide.0,drive=LinuxDVD -drive id=LinuxDVD,if=none,snapshot=on,media=cdrom,file=I:\OS\Images\HighSierra.iso -accel hax

HAX is working and emulator runs in fast virt mode. C:\Programmi\qemu\qemu-system-x86_64: warning: Ignoring ROMD region 0x00000000ffc84000->0x0000000100000000 C:\Programmi\qemu\qemu-system-x86_64: warning: Ignoring ROMD region 0x00000000ffc00000->0x00000000ffc84000 VCPU shutdown request VCPU shutdown request VCPU shutdown request VCPU shutdown request VCPU shutdown request VCPU shutdown request VCPU shutdown request VCPU shutdown request

[raphaelning]

We don't plan to provide official support for running macOS guests, but we're open to pull requests for this feature.

"VCPU shutdown request" indicates a panic in the HAXM driver. Could you post the HAXM driver log?

[HaHoYou]

The HAXM driver log can be got from Windbg. Also, would you help to provide the MacOS iso file and other files you used, as well as the method how you made them.

[Marietto2008]

Thanks. You can find everything below (the mac os x high sierra iso file and the log file). PS : About how I have obtained the mac os x iso file : I got it following this tutorial : https://github.com/kholia/OSX-KVM/tree/master/HighSierra

https://drive.google.com/open?id=1sYLvF8tgd3baCD-IVoAJ1kpx8SggyqOq

[Marietto2008]

Anyway,I have attached the log file below..

High_Sierra.LOG

[Marietto2008]

Everything is ok ? did u get everything you need ?

Il giorno gio 3 gen 2019 alle ore 05:10 Huang, Jun notifications@github.com ha scritto:

The HAXM driver log can be got from Windbg. Also, would you help to provide the MacOS iso file, as well as the method how you made it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149#issuecomment-451052069, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuGixcQ_emJumj47PyZtq_dd2QXTQdmks5u_YKhgaJpZM4ZmoLk .

-- Mario.

[raphaelning]

did u get everything you need ?

Yes, thanks for providing all the details! It seems the error has nothing to do with the macOS guest image (mac_hdd.img or HighSierra.iso), because I was able to reproduce the same error with the following QEMU command:

qemu-system-x86_64 -machine q35 -drive if=pflash,format=raw,readonly,file=X:\path\to\OSX-KVM\OVMF_CODE.fd -accel hax

Without -accel hax, QEMU can boot to the OVMF shell. Therefore, the first step is to get OVMF working on HAXM. This is the first time we have tested booting UEFI firmware (OVMF) on HAXM, so there can be surprises.

[HaHoYou]

Yes, we got them, thanks.

[Marietto2008]

news ?

[raphaelning]

Today we received an important tip from the QEMU community (many thanks to @AlexAltea) on why OVMF doesn't yet run on HAXM:

http://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg08482.html

If we implement the proposed changes, we should be a big step closer to getting OVMF booting.

[Marietto2008]

nice.

[ewoks]

any progress on this? tnx

[tibidi]

I have the same issue any progress ?

[Marietto2008]

do u remember me ? any progress ?

Il giorno mar 1 ott 2019 alle ore 17:54 TIBIDI notifications@github.com ha scritto:

I have the same issue any progress ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149?email_source=notifications&email_token=AAFYNC5TUNO7S5ML5CZUQOLQMNXEZA5CNFSM4GM2QLSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEABYWTA#issuecomment-537103180, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFYNC4ZK6M2KHB4LKUMD4DQMNXEZANCNFSM4GM2QLSA .

-- Mario.

[HaHoYou]

The guest of Darwin has not been supported so far. Unfortunately, we have not prioritized this feature in our development plans yet. If community contributors are willing to investigate this feature, it will be welcomed and we will provide corresponding supports. We will record your requirements in order to include it in the future development plans. Thank you.

[Marietto2008]

this is not a good behavior. i remember very well your enthusiasm the first time that i ve asked some help by you. you had taken in serious consideration to work on that as one of your priority. now you are coming back to your steps. you dont seem to be mature guys.

Il lun 14 ott 2019, 08:41 Huang, Jun notifications@github.com ha scritto:

The guest of Darwin has not been supported so far. Unfortunately, we have not prioritized this feature in our development plans yet. If community contributors are willing to investigate this feature, it will be welcomed and we will provide corresponding supports. We will record your requirements in order to include it in the future development plans. Thank you.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149?email_source=notifications&email_token=AAFYNC4V6S4RTCS7MYATZTTQOQIBFA5CNFSM4GM2QLSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBDPFTA#issuecomment-541520588, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFYNC2QIBAKGFKUK4V5TRTQOQIBFANCNFSM4GM2QLSA .

[HaHoYou]

Great thanks for your previous information from raising this issue to providing the detailed logs. All of these contributions helped us to narrow down the original issue to the OVMF booting support. We had already marked this issue as a feature in January of this year, and we are very open to discuss the implementation of this feature and welcome any pull request for it. Currently, we are busy in solving the issues reported by Android SDK customers and our focus is mainly targeted to Android Emulator, sorry for delayed response. Thanks for you understanding.

[nevilad]

Is OVMF_CODE.fd MacOS bios image? Can MacOs run with bioses shipped with qemu? The error can be reproduced using this command line: qemu-system-x86_64 -machine q35 -drive if=pflash,format=raw,readonly,file=X:\path\to\OSX-KVM\OVMF_CODE.fd -accel hax Does this mean that it is possible to run MacOs without hdd and installation iso? Since it is possible to reproduce the bug usng only OVMF_CODE.fd, can I download only this file somewhere?

[nevilad]

With some patches in qemu and hax I'm able to run MacOS. It requires exactly Penryn CPU version in cpuid1.eax. I don't wan't to change the code to return exactly this version, instead qemu should set it through specific ioctls. But there are no ioctls for doing this yet. KVM API has an ioctl for setting values returned by cpuid. It would be good to make exactly this API in hax, but it does not allow to set only one register for cpuid. Any suggestions for solving this problem? Should hax move towards KVM-like ioctl API? @AlexAltea mentioned that it would be good to adopt the KVM API https://github.com/intel/haxm/issues/106#issuecomment-432844665 and created https://github.com/intel/haxm/pull/121.

[oliverhbailey]

I am working on a book developing for UEFI. I've been writing operating system drivers, and developing custom hardware for over 40 years. And I co-authored some very early PC applications and developer tools. I have had issues with UEFI in a virtual environment. First off, OVMF development isn't supported in VirtualBox, as the emulator is incomplete. They note that fact in the documentation. What does surprise me is the fact that HAXM doesn't support protected ROM areas when used with QEMU. The reason I need this is for screen captures for the book. My screen capture and screen recording software works on Windows, so I routinely run Linux and OVMF in qemu to capture these screens. Since Intel is a member of the "Unified" group developing UEFI, it would seem there would be better support and less time making excuses why it won't work. You cannot support Mac, if you don't support UEFI. If any executive from Intel would be willing to explain this, I would be interested in hearing what the have to say. You can't finish the UEFI implementation of make the BIOS completely transparent until you have a plan to make it work with QEMU. Maybe you should consider using kvm to support the Intel emulator and move forward so kernel and driver developers can help you move forward. The following is the error message generated by haxm 7.5.6 on Windows 10.1 build 1903. qemu-system-x86_64: warning: Ignoring ROMD region 0x00000000ffc84000->0x0000000100000000

This is just the OVMF_CODE.fd ROM image. The same happens for the OVMF_VARS.fd ROM image as well.

If the right person reads this who is on the HAXM team, allocating a reserved area for ROM images is going to be a requirement anyway, since many hardware devices install ROM images during the POST phase of the BIOS.

HaHoYou needs to stop making excuses for this and start finding the right people in the HAXM group at Intel to get this moving NOW. You can't finish developing UEFI without prioritizing this facet of development.

If anyone at Intel who is involved with HAXM development reads reads this. Contact me directly through LinkedIn.

Regards, Oliver Bailey

[nevilad]

The patch for supporting ROMD in qemu for hax is ready. Same for supporting MacOS in hax. These were ready at the time of my last post in this issue. They depend on some other patches in qemu and hax, which are not yet accepted. When these are accepted and merged, I will create a PR for solving this issue which includes ROMD support.

[oliverhbailey]

Approximately how long do you anticipate approval will take? My book is a few days from completion, so if this is going to take more than a few weeks, I need to let the publisher know.

Thank you, Oliver Bailey

On Mon, Mar 16, 2020, 2:22 PM nevilad notifications@github.com wrote:

The patch for supporting ROMD in qemu for hax is ready. Same for supporting MacOS in hax. These were ready at the time of my last post in this issue. They depend on some other patches in qemu and hax, which are not yet accepted. When these are accepted and merged, I will create a PR for solving this issue which includes ROMD support.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149#issuecomment-599717508, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6CBICDHM4WZPANTQIPCULRHZ37NANCNFSM4GM2QLSA .

[hyuan3]

HAXM has merged ROMD support. But needs another patch below in Qemu to be accepted. Let me ping Qemu community. https://lists.sr.ht/~philmd/qemu/patches/6470

[oliverhbailey]

Thank you.

Oliver

On Tue, Mar 17, 2020, 2:15 AM hyuan3 notifications@github.com wrote:

HAXM has merged ROMD support. But needs another patch below in Qemu to be accepted. Let me ping Qemu community. https://lists.sr.ht/~philmd/qemu/patches/6470

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149#issuecomment-599913562, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6CBIAT5KMTA5GRBN4G2BLRH4PPHANCNFSM4GM2QLSA .

[nevilad]

Approximately how long do you anticipate approval will take?

At best two weeks, but I think it will take longer. How do yo want to test ROMD support? MacOS won't run with the uploaded qemu patch.

[oliverhbailey]

Ok.

Send me the patch and I'll tessd's t on linux snd qemu for you. It will probsbly be tomorrow morning before I test.

Oliver

On Tue, Mar 17, 2020, 1:21 PM nevilad notifications@github.com wrote:

Approximately how long do you anticipate approval will take?

At best two weeks, but I think it will take longer. How do yo want to test ROMD support? MacOS won't run with the uploaded qemu patch.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149#issuecomment-600225464, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6CBIC33RQCVQ6DZHTNUV3RH65SJANCNFSM4GM2QLSA .

[nevilad]

I've tried to run the patched version but it doesn't run anymore. I worked in the this branch on other features and it seems they affected the result. I don't have time now to debug it, so cant't help you now.

[oliverhbailey]

Ok.

Thanks

On Wed, Mar 18, 2020, 3:44 AM nevilad notifications@github.com wrote:

I've tried to run the patched version but it doesn't run anymore. I worked in the this branch on other features and it seems they affected the result. I don't have time now to debug it, so cant't help you now.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149#issuecomment-600495349, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6CBIGSDDQARLERMNZM2G3RICCX3ANCNFSM4GM2QLSA .

[oliverhbailey]

Does anyone here have a real interest in getting OVMF working with QEMU and HAXM. If not, someone should turn this back to Intel since they wrote the original code. It seems there are a lot of people here with smiles and good intentions, but no one with the time or skills to actually fix this. Get off your backside and either get this fixed, or send it back to the QEMU, KVM, and HAXM project contributors, and tell them you can't or won't do this. This is vital to be able to use and test UEFI code in emulation.

[arrmo]

Very interested here as well - is there a patched / hacked version to try? No issues here building QEMU if needed.

Thanks!

[arrmo]

Hi,

OK, I have a build "running" here - I think it may be what you're meaning ... hax is working, but with the noted patch it just hangs. I output the serial log, here is what I see. Thoughts?

!!!! X64 Exception Type - 00(#DE - Divide Error)  CPU Apic ID - 00000001 !!!!
RIP  - 000000001F88FBFF, CS  - 000000007FEB1E5C, RFLAGS - 0000000000000018
RAX  - 0000000000000001, RCX - 000000007FEB1E9C, RDX - 000000007FECC5BD
RBX  - 0000000000000020, RSP - 0000000000000001, RBP - 000000007FEB1E7C
RSI  - 000000007FECC5BD, RDI - 0000000003000000
R8   - 0000000003000000, R9  - 000000007FECC5BD, R10 - 000000007FEB1EBC
R11  - 0000000000000001, R12 - 000000007FEB1ECC, R13 - 0000000000000001
R14  - 000000007FECA460, R15 - 000000007FECC5BD
DS   - 0000000000000000, ES  - 0000000000000000, FS  - 0000000000000018
GS   - 000000007FEB0001, SS  - 0000000000000001
CR0  - 000000000000021F, CR2 - 0000000000000008, CR3 - 0000000000000008
CR4  - 0000000000000018, CR8 - 0000000000000018
DR0  - 0000000000010046, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3  - 00000000FFFFFF80, DR6 - 000000000000001F, DR7 - 000000007BF3DD80
GDTR - 000000000009F000 000000007FEB0000, LDTR - 0000000000000008
IDTR - 000000007FEB1E80 0000000000000000,   TR - 000000000009F1A1
FXSAVE_STATE - 000000007FEB1B40
!!!! Find image based on IP(0x1F88FBFF) /home/build/edk2/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe/DEBUG/VariableRuntimeDxe.dll (ImageBase=0000000000B99444, EntryPoint=0000000000B9EF0F) !!!!
!!!! X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 00000002 !!!!
ExceptionData - 0000000000000018
RIP  - 000000000009F009, CS  - 0000000000000018, RFLAGS - 0000000000010046
RAX  - 0000000000000018, RCX - 000000007FEB0001, RDX - 000000001F88FBFF
RBX  - 0000000000000000, RSP - 000000007FEB1E80, RBP - 000000007FEB0000
RSI  - 000000000009F000, RDI - 000000000009F1A1
R8   - 0000000000000000, R9  - 0000000000000000, R10 - 000000007FEB1E5C
R11  - 0000000000000001, R12 - 0000000003000000, R13 - 000000007FECC5BD
R14  - 000000007FEB1E7C, R15 - 0000000000000001
DS   - 0000000000000018, ES  - 0000000000000018, FS  - 0000000000000008
GS   - 0000000000000008, SS  - 0000000000000008
CR0  - 00000000E0000013, CR2 - 0000000000000000, CR3 - 0000000000800000
CR4  - 0000000000000228, CR8 - 0000000000000000
DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 00000000FFFFFF80 000000000000001F, LDTR - 0000000000000000
IDTR - 000000007BF3DD80 000000000000021F,   TR - 0000000000000000
FXSAVE_STATE - 000000007FEB1AE0
!!!! Can't find image information. !!!!

Thanks!

[arrmo]

Hmmm ... this looks exactly like what I'm seeing, https://www.reddit.com/r/VFIO/comments/84f1xn/ovmf_crashes_on_boot/

I admit, not quite sure where to find a newer / corrected OVMF. That's a bit above my pay grade ... LOL!

[oliverhbailey]

Did you download the OVMF source or binary? I didn't crash HAXM, it exited when initialized via QEMU. I am going to try the patches for QEMU this morning. The OVMF that I used was the same build that I fetched from get hub and built.

I hope this helps.

Oliver

On Tue, Apr 7, 2020 at 5:15 PM arrmo notifications@github.com wrote:

Hmmm ... this looks exactly like what I'm seeing, https://www.reddit.com/r/VFIO/comments/84f1xn/ovmf_crashes_on_boot/

I admit, not quite sure where to find a newer / corrected OVMF. That's a bit above my pay grade ... LOL!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149#issuecomment-610647062, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6CBIEZQBTDNIB24M3RIDLRLOQYVANCNFSM4GM2QLSA .

[arrmo]

Hi,

I downloaded the binary (pre-built image, from https://www.kraxel.org/repos/) ... that may be wrong, I admit! And from there, I took the x64 version, "pure-efi" as it is labeled ... is that correct?

Thinking this is just the first step ... I can't even get to an EFI shell (i.e. so this is OVMF, not worried about macOS yet ... LOL).

Thoughts?

Thanks!

[arrmo]

Just a thought, but ... should we "minimize" the command line for this testing, limit to (only) UEFI, CPU ... the bare minimum? Meaning - no other drives, boot attempt. Crawl before walk / run? 😄

Thanks!

[oliverhbailey]

Henry, I have been using the qemu-system-x86_64.exe qemu version on Windows 10. I installed that from the site of the maintainer. Is that the correct version. Second, the invocation line for QEMU is attached. It appears haxm is not loading, getting an error 31 when the sc start command is issued. Please advise if I should install the patch from yesterday and verify which qemu application should be patched.

Regards, Oliver Bailey

On Wed, Apr 8, 2020 at 11:21 AM arrmo notifications@github.com wrote:

Hi,

I downloaded the binary (pre-built image, from https://www.kraxel.org/repos/) ... that may be wrong, I admit! And from there, I took the x64 version, "pure-efi" as it is labeled ... is that correct?

Thinking this is just the first step ... I can't even get to an EFI shell (i.e. so this is OVMF, not worried about macOS yet ... LOL).

Thoughts?

Thanks!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149#issuecomment-611055064, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6CBIAMXRD5R33U6JEUHE3RLSQA3ANCNFSM4GM2QLSA .

[arrmo]

Hi,

I have the master building and working here - with the patch applied to correct the (haxm) issue that currently exists in the master. Is that what you are using as well.

My sc command works well - yours failing? What shell are you using to execute it? I know, sounds like a dumb question but I got fooled by CMD vs. WSL ... 😞

[oliverhbailey]

Which master are your using? Windows or Linux? I am using the qemu-system-x86_64.exe for WIndows and it isn't clear which master I need to patch. I have not done patching on this before so I am not certain which patch program to use.

sc works fine, you can't run a windows executable on Windows Subsystem for Linux; it's a container running Linux on Windows, the two system are isolated from one another, so that shouldn't work. I use sc on the command line as Administrator and it works fine.

WSL is Linux, CMD is WIndows.

I hope that helps.

Regards, Oliver

On Wed, Apr 8, 2020 at 1:57 PM arrmo notifications@github.com wrote:

Hi,

I have the master building and working here - with the patch applied to correct the (haxm) issue that currently exists in the master. Is that what you are using as well.

My sc command works well - yours failing? What shell are you using to execute it? I know, sounds like a dumb question but I got fooled by CMD vs. WSL ... 😞

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149#issuecomment-611132702, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6CBIATGAEDHR7HTTMRYZLRLTCJZANCNFSM4GM2QLSA .

[arrmo]

Yes, agreed on WSL vs. CMD! Was just guessing why you may be having sc issues - but if it's working now, that's great. BTW, I am able to run qemu-system-x86_64 in either (WSL v2 here).

On the master - pulling the latest (QEMU) code from GitHub. I (manually) applied the patch, cross-compiled and installed. That's all working. Just breaks when trying to use it with OVMF.

Thanks!

[oliverhbailey]

Let me explain what works - QEMU without the haxm emulator works without a problem loading the OVNF.bin and OVMF.vars images. The command Line is:

PS C:\WINDOWS\system32> qemu-system-x86_64 -drive if=pflash,format=raw,unit=0,file=c:\"program files"\qemu\x64\OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=c:\"program files"\qemu\x64\OVMF_VARS.fd -drive file=c:\users\zzf66\desktop\deb10-uefi-train,index=0,media=disk,format=raw -m 3072 -smp 3

That works fine and boots a custom UEFI ROM and uses the vars as shown in file2.png.

In my case, once the system fully boots the efi executable programs will be in the "/boot/efi/EFI/debian" folder.

The EFI variables will reside in "/sys/firmware/efi/efivars"

You can list the contents of the first command line or cat the efivars file, buth using the sudo command. That verifies the binary images were loaded and read.

I problem is I have is limited to haxm. when I added -accel haxm to the qemu command line, I got the message following the command in file3.png before updating to haxm 7.6.1

Now I get the error shown in file1.png

So as you can see, my problem is only using haxm, and works fine if I execute a standard non-hypervisor qemu command line.

[arrmo]

Not seeing the noted pics, but I have exactly the same issue ... works fine with OVMF, issue is specifically haxm + OVMF. Not at all related to macOS.

So do we open a different ticket, not to tie this to macOS? And of course ... any suggestions of how to resolve?

Thanks!

[oliverhbailey]

The screen captures were attachments.

I think we're pretty much on our own on this one. It appears to me the people working on this project just don't have the skills to fix haxm. It aso seems clear that Windows and Mac users for QEMU are not many in numbers.

My work around to to change my Linux development system from using Wayland, back to X11. The reason for me using this was because I need to shoot screen videos and captures of UEFI development, and my video and screen capture tools are all Windows based. With Wayland, I can't use VNC or RDP to log across. But I replaced Wayland with X on my VM, and I can do it within 15 minutes on my development system and get around the problem, and that seems like a better solution.

You may have options as well. If you'r doing UEFI development, you could get a second hard disk and install Debian 10 on that, setting your Mac up to dual boot or install Debian 10 to an external USB 3.0 hard disk, and use it to dual boot from from an external drive. I sold the Mac several years ago, so I am not certain what current options are.

This problem has been around for over 3 years on the Mac and Windows, and it keeps coming back, so it's doubtful they will get this working. And I could fix it, but I don't really have the time. I have many systems, so its easier to configure one them to work on Linux.

Good luck with this. If you need any suggestions feel free to contact me.

Regards, Oliver Bailey

On Wed, Apr 8, 2020, 8:06 PM arrmo notifications@github.com wrote:

Not seeing the noted pics, but I have exactly the same issue ... works fine with OVMF, issue is specifically haxm + OVMF. Not at all related to macOS.

So do we open a different ticket, not to tie this to macOS? And of course ... any suggestions of how to resolve?

Thanks!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/intel/haxm/issues/149#issuecomment-611271459, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6CBICV5ISAWZI6TCNDEKDRLUNQDANCNFSM4GM2QLSA .

[nevilad]

I've uploaded my code for supporting MacOS and ROMD, you can try it - https://github.com/intel/haxm/pull/288.

[arrmo]

Hi,

Just a quick note, need to dig more - but I was trying something here ... went back to a very basic setup, to show the problem with ONLY haxm and UEFI ... and the EFI shell came up! Started adding items back, and it broke when I added smp. Try removing that in your command line, let me know if you see any progress?

Thanks!

[arrmo]

I've uploaded my code for supporting MacOS and ROMD, you can try it - #288.

Just apply that one patch (hax-mem.c), right? Or other changes needed?

Asking because I tried it, Clover starts to boot, but then just hangs 😞

Thanks!

[nevilad]

Only that patch. Can you paste a screenshot?

[arrmo]

Sure! Here you go, thoughts?

[nevilad]

What are your host and guest OSes? Paste full qemu command line please.

[arrmo]

Sure! Host = Windows 10, Guest = macOS (Catalina),

'/mnt/c/Program Files/qemu/qemu-system-x86_64.exe' -m 2048 \
      -boot menu=on \
      -machine q35 \
      -usb -device usb-kbd -device usb-mouse \
      -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \
      -drive if=pflash,format=raw,readonly,file=$OVMF/OVMF_CODE.fd \
      -drive if=pflash,format=raw,file=$OVMF/OVMF_VARS-1024x768.fd \
      -smbios type=2 \
      -device ich9-ahci,id=sata \
      -drive id=Clover,if=none,snapshot=on,format=qcow2,file=./'Catalina/CloverNG.qcow2' \
      -device ide-hd,bus=sata.2,drive=Clover \
      -device ide-hd,bus=sata.3,drive=InstallMedia \
      -drive id=InstallMedia,if=none,file=BaseSystem.img,format=raw \
      -drive id=MacHDD,if=none,file=./macOS.img,format=qcow2 \
      -device ide-hd,bus=sata.4,drive=MacHDD \
      -drive id=ESP,if=none,format=vdi,file=OpenCore.vdi \
      -device ide-hd,bus=sata.5,drive=ESP \

[nevilad]

1) This issue contains a link to google disc, where all needed files can be downloaded. Did you get OVMF_CODE.fd, OVMF_VARS-1024x768.fd and CloverNG.qcow2 there? 2) Your command line is different from the one in this issue description. You replaced Clover bus from ide to sata? 3) Did you see this screen, is your error before or after it:

[nevilad]

4) BaseSystem.img is the installation media of catalina? 5) What is OpenCore.vdi and where did you get it?