Some recent UEFI implementations have begun to leave the CPU with page write protection enabled in CR0.
With r330539 which enables kernel page protections, interesting things happen during boot (aka panic) when protection is already enabled, including a write protection fault from an explicit .text fixup write from xsave->xsaveopt by fpuinit(). I see this so far booting -CURRENT under virtual environments: - QEMU with recent OVMF EDK2 builds: this is certainly due to UEFI enabling paging and page protections. - VMWare Fusion 10.1.x on Mac: no specific insight on what's going inside the implementation, but CR0_WP is definitely left enabled before the kernel is booted. I have patched my kernel build to explicitly clear CR0_WP (e.g. in initializecpu) prior to creating the page tables to get around this, but someone might have a cleaner/better solution... --peter
smime.p7s
Description: S/MIME Cryptographic Signature
