On Sat, Aug 05, 2017 at 10:05:09PM +0200, Laszlo Ersek wrote:
> On 08/05/17 13:46, Dhiru Kholia wrote:
> > On Sat, Aug 5, 2017 at 2:00 PM, Dhiru Kholia <dhiru.kho...@gmail.com> wrote:
> >> I ran git bisect on OVMF repository [5] to find the commit that broke
> >> booting of macOS + Clover combination in QEMU/KVM.
> >>
> >> It seems that commit 805762252733bb is problematic for some reason.
> >> Reverting this commit fixes the macOS booting problem.
> >>
> >> In summary, I am able to boot macOS 10.12.5 + Clover combination with
> >> latest OVMF (commit 1fceaddb12b with 805762252733bb reverted) +
> >> updated QEMU (commit aaaec6acad7c with patch from this thread
> >> applied).
> > 
> > After some more testing,
> > 
> > I am also able to boot macOS 10.12.5 + Clover combination with latest
> > OVMF (commit 1fceaddb12b with 805762252733bb reverted) + updated QEMU
> > (commit ac44ed2afb7c60 *without* my patch from this thread).
> I don't know how edk2 commit 805762252733 ("OvmfPkg/AcpiPlatformDxe:
> save fw_cfg boot script with QemuFwCfgS3Lib", 2017-02-23) can cause your
> symptoms.
> (snipped)

Hi Laszlo,

Thanks a lot for your detailed answers, and great tips.

For all of the following results, I have used OVMF commit 1fceaddb12b59,
without any patches reverted.

> You could try the following:
> (1) Disable S3 support on the QEMU command line. OVMF will recognize
> that, and skip all the S3 opcode recording (and memory reservation).
> IIRC OSX requires Q35, so I'll give you the command line option for Q35:
>   -global ICH9-LPC.disable_s3=1

-machine pc-q35-2.4 -global ICH9-LPC.disable_s3=1

This combination works fine. I was able to boot macOS 10.12.5 + Clover with

> (2) Set "PcdDebugPrintErrorLevel" in "OvmfPkg/OvmfPkgX64.dsc" to
> 0x8040004F, then rebuild OVMF. Additionally, append the following to the
> QEMU command line:
>   -debugcon file:ovmf.debug.log -global isa-debugcon.iobase=0x402
> We can then look at the OVMF debug log.

I have attached the compressed logs to this email.

q35-2.4-ovmf.debug.log.tar.gz is for "pc-q35-2.4" machine type and
q35-2.5-ovmf.debug.log.tar.gz is for "pc-q35-2.5".

The "pc-q35-2.4" machine doesn't boot but "pc-q35-2.5" works fine.

I did not use the "ICH9-LPC.disable_s3=1" option for these results.

> (3) Hm... are you perhaps using the pc-q35-2.4 machine type? If so, can
> you try pc-q35-2.5 or later?
> ... Yes, you are using pc-q35-2.4:
> https://github.com/kholia/OSX-KVM/blob/master/boot-clover.sh
> https://github.com/kholia/OSX-KVM/blob/master/boot-macOS.sh

The "pc-q35-2.5" machine type works great without any extra options with
pristine latest QEMU and OVMF sources! I will update my macOS boot
script to use this (or higher) machine type.

> Sigh, I see now what it is. It's indeed an OVMF bug, introduced in
> commit 805762252733.
> Basically what I think I messed up in 805762252733 is that if you have
> S3 enabled, OvmfPkg/AcpiPlatformDxe will incorrectly / indirectly insist
> that you also have the DMA feature for fw_cfg, even if you have zero
> WRITE_POINTER commands. pc-q35-2.4 has no DMA for fw_cfg, and S3 is
> enabled by default in upstream QEMU and libvirt. OvmfPkg/AcpiPlatformDxe
> incorrectly thinks this is bad and rolls back all the ACPI linker/loader
> stuff -- you end up with the built-in (very outdated) fallback ACPI tables.
> I'll try to send out a patch next week and CC you for testing. Please
> subscribe to edk2-devel at
> <https://lists.01.org/mailman/listinfo/edk2-devel> first, otherwise the
> list will drop your messages.
> Just to confirm my suspicion, can you please do all three steps / checks
> above?

I have subscribed to the edk2-devel list now. I would be happy to test
your upcoming patch.

I believe that you have already figured out this whole thing :-)


Attachment: q35-2.4-ovmf.debug.log.tar.gz
Description: application/gzip

Attachment: q35-2.5-ovmf.debug.log.tar.gz
Description: application/gzip

Reply via email to