qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] pc/acpi: Fix booting of macOS with Clover EFI b


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH] pc/acpi: Fix booting of macOS with Clover EFI bootloader
Date: Sun, 6 Aug 2017 11:35:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 08/06/17 09:38, Dhiru Kholia wrote:
> 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 <address@hidden> 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
> it.
> 
>> (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

Yup, the log says

"AcpiPlatform: QemuFwCfgS3CallWhenBootScriptReady: fw_cfg DMA unavailable"

> and q35-2.5-ovmf.debug.log.tar.gz is for "pc-q35-2.5".

whereas this one says

"InstallQemuFwCfgTables: installed 6 tables"

Thank you for confirming the analysis. (Also thanks for the careful
testing; it's nice to see when someone takes care to isolate the moving
parts from each other.) I'll send the patch soon and CC you.

Sorry about the regression.

Cheers,
Laszlo

> 
> 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 :-)
> 
> Thanks,
> Dhiru
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]