search

acidanthera / bugtracker

Acidanthera Bugtracker
374 stars 42 forks source link

Make SetupVirtualMap work with read only page tables #719

Closed vit9696 closed 4 years ago

vit9696 commented 4 years ago

Currently SetupVirtualMap implementation expects page table (pointed by CR3) memory to be writeable, which is not the case with at least current OVMF implementation as shown in https://github.com/acidanthera/bugtracker/issues/531#issuecomment-586510543.

Currently the crash happens in VmMapVirtualPage when trying to write to PML4. To resolve this we need to copy page tables before altering them.

Marking as low priority due to no known firmwares having page table protection at the same time of requiring SetupVirtualMap quirk. We should most likely mention this in the docs though.

steeve commented 4 years ago

Thank you for being so responsive.

steeve commented 4 years ago

Indeed disabling SetupVirtualMap fixes the crash. The VM reboots now, but that's probably due to some other issue.

steeve commented 4 years ago

This may be the reason why: https://www.nicksherlock.com/2018/04/patch-ovmf-to-support-macos-in-proxmox-5-1/

I wasn't using OVMF from OSX-KVM, and indeed with it SetupVirtualMap can be enabled.

steeve commented 4 years ago

Indeed: https://github.com/kholia/edk2/commit/b20acb459737b6d60f1ef49712dd6e05fd7b2bb9

vit9696 commented 4 years ago

@steeve, SetupVirtualMap should not be needed with OVMF, so I expect stock OVMF (without these patches) to work just fine with SetupVirtualMap disabled. Cannot you confirm this?

steeve commented 4 years ago

Indeed with Clover + VirtualBox I didn't need AptioMemoryFix.efi

That said, I'm using QEMU + hvf on a real mac, and after OC the VM just shuts down without any error. Same happens with Clover.

vit9696 commented 4 years ago

So, does that mean that without reverting the change you mentioned (i.e. disabling page protection) and enabling SetupVirtualMap macOS does not launch in QEMU?

vit9696 commented 4 years ago

CC @Download-Fritz

steeve commented 4 years ago

So:

In both cases though QEMU+hvf fails to start with either Clover or OpenCore (I had hopes OpenCore would boot).

Without hvf (slow), the kernel boots in the no exception case, but fails on some CoreCrypto thingy (haven't investigated yet).

vit9696 commented 4 years ago

So, does it mean that macOS simply is not supported by HVF in QEMU? This sounds most logical to me, as I believe SetupVirtualMap is not needed and reverting that patch is not needed either.

steeve commented 4 years ago

That is very probable indeed. You're saying HVF would need to have special support for macOS?

vit9696 commented 4 years ago

Yes and no. Operating systems may require special features from the virtual machine to support them. For example, haxm accelerator currently also does not support macOS. However, Parallels and formerly Veertu (they opensourced something based on QEMU not too long ago, which can still be found e.g. here) work fine with HVF. So it is not impossible to emulate macOS with QEMU + HVF, but you may have to debug/fix that.

steeve commented 4 years ago

I guess that would be the same for Hyper-V too right?

How would one go about finding how to debug it? The VM just stopping is kind of low on informations :D

vit9696 commented 4 years ago

Yes, likely. I would say my first try would be to try to trace the guest with the debugger. We have scripts here, which should also work for QEMU. Other than that, QEMU should have some builtin tracing features, but I am not aware of them well enough to provide a decent overview.

vit9696 commented 4 years ago

Taking all things into consideration we decided not to implement this as no modern firmwares need SetupVirtualMap in the first place, and only them will not work with SetupVirtualMap enabled.