On 06/29/15 20:10, Ard Biesheuvel wrote: > On 29 June 2015 at 17:12, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >> On 29 June 2015 at 17:09, Matt Fleming <m...@codeblueprint.co.uk> wrote: >>> On Mon, 29 Jun, at 03:06:32PM, Laszlo Ersek wrote: >>>> >>>> In any case, for OVMF, I think we'll need a small patch that disables >>>> this feature (if for nothing else, then to quell the noisy warnings >>>> about "the section alignment being != 4 KB"). I'm adding that to my >>>> queue (but anyone please feel free to do it while I'm offline). >>> >>> Is there any chance that we could wire up support in OVMF? What work is >>> required to support it? >>> >> >> I think it would be fairly easy, actually, once Laszlo manages to >> untangle the S3Save mess so that OVMF signals EndOfDxe correctly. >> Then, it is mainly a matter of using the new build script that emits 4 >> KB aligned segments for .text and .data >> > > This seems to do the job nicely: > > ----------8<------------ > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > index e5fc90d2e610..7f06b51f65cf 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -48,6 +48,9 @@ [BuildOptions] > INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable > !endif > > +[BuildOptions.X64.EDKII.DXE_RUNTIME_DRIVER] > + GCC:*_*_*_DLINK_FLAGS = > --script=$(EDK_TOOLS_PATH)/Scripts/gcc-4K-align-ld-script > + > > ################################################################################ > # > # SKU Identification section - list of all SKU IDs supported by this > Platform. > ----------8<------------ > > $ readelf -S > Build/OvmfX64/DEBUG_GCC48/X64/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb/DEBUG/EmuVariableFvbRuntimeDxe.dll > > Section Headers: > [Nr] Name Type Address Offset > Size EntSize Flags Link Info Align > ... > [ 1] .text PROGBITS 0000000000001000 00001000 > 0000000000004780 0000000000000000 AX 0 0 4096 > ... > [ 3] .data PROGBITS 0000000000006000 00006000 > 0000000000002740 0000000000000000 WA 0 0 4096 > ... > > > With Laszlo's 9 piece series applied to ensure that end of DXE gets > signalled, UEFI seems to do the right thing here. Here's a snippet of > my boot log (x86_64) > > [ 0.000000] efi: mem22: type=6, attr=0x800000000000400f, > range=[0x0000000006daa000-0x0000000006db1000) (0MB) > [ 0.000000] efi: mem23: type=5, attr=0x800000000002000f, > range=[0x0000000006db1000-0x0000000006db6000) (0MB) > [ 0.000000] efi: mem24: type=6, attr=0x800000000000400f, > range=[0x0000000006db6000-0x0000000006dc0000) (0MB) > [ 0.000000] efi: mem25: type=6, attr=0x800000000000400f, > range=[0x0000000006dc0000-0x0000000006dc1000) (0MB) > [ 0.000000] efi: mem26: type=5, attr=0x800000000002000f, > range=[0x0000000006dc1000-0x0000000006dc5000) (0MB) > [ 0.000000] efi: mem27: type=6, attr=0x800000000000400f, > range=[0x0000000006dc5000-0x0000000006dce000) (0MB) > [ 0.000000] efi: mem28: type=6, attr=0x800000000000400f, > range=[0x0000000006dce000-0x0000000006dcf000) (0MB) > [ 0.000000] efi: mem29: type=5, attr=0x800000000002000f, > range=[0x0000000006dcf000-0x0000000006dd5000) (0MB) > [ 0.000000] efi: mem30: type=6, attr=0x800000000000400f, > range=[0x0000000006dd5000-0x0000000006e02000) (0MB) > [ 0.000000] efi: mem31: type=6, attr=0x800000000000400f, > range=[0x0000000006e02000-0x0000000006e03000) (0MB) > [ 0.000000] efi: mem32: type=5, attr=0x800000000002000f, > range=[0x0000000006e03000-0x0000000006e12000) (0MB) > [ 0.000000] efi: mem33: type=6, attr=0x800000000000400f, > range=[0x0000000006e12000-0x0000000006e1a000) (0MB) > > so code and data regions are correctly marked as RO and XP, respectively. > > However, further down I get > > [ 0.034428] BUG: unable to handle kernel paging request at fffffffefe60d64d > [ 0.036000] IP: [<fffffffefe60d64d>] 0xfffffffefe60d64d > [ 0.036000] PGD 4c11067 PUD 601b063 PMD 6028063 PTE 0 > [ 0.036000] Oops: 0010 [#1] SMP > [ 0.036000] Modules linked in: > [ 0.036000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.13.0-55-generic #94-Ubuntu > [ 0.036000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS 0.0.0 02/06/2015 > [ 0.036000] task: ffffffff81c15480 ti: ffffffff81c00000 task.ti: > ffffffff81c00000 > [ 0.036000] RIP: 0010:[<fffffffefe60d64d>] [<fffffffefe60d64d>] > 0xfffffffefe60d64d > [ 0.036000] RSP: 0000:ffffffff81c01d48 EFLAGS: 00000202 > [ 0.036000] RAX: fffffffefe60d64d RBX: ffffffffffffffff RCX: > ffffffff81c396e0 > [ 0.036000] RDX: ffffffff81c01f00 RSI: ffffffff81c396e0 RDI: > fffffffefe40a957 > [ 0.036000] RBP: ffffffff81c01e00 R08: 0000000000000007 R09: > 0000000000000000 > [ 0.036000] R10: ffffea0000180e00 R11: ffffffff81d51ce0 R12: > ffffffff81c01f00 > [ 0.036000] R13: 0000000000000000 R14: 0000000000000007 R15: > 000000000009c000 > [ 0.036000] FS: 0000000000000000(0000) GS:ffff880006600000(0000) > knlGS:0000000000000000 > [ 0.036000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.036000] CR2: fffffffefe60d64d CR3: 000000000009c000 CR4: > 00000000000006b0 > [ 0.036000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 > [ 0.036000] DR3: 0000000000000000 DR6: 0000000000000000 DR7: > 0000000000000000 > [ 0.036000] Stack: > [ 0.036000] fffffffefe40aa08 ffffffff81c01da0 0000000007eb3893 > 0000000006db7000 > [ 0.036000] 0000000006db7000 0000000006dba000 0000000007eed090 > 0000000000000078 > [ 0.036000] 752ea16d07eede98 ffffffff81c01de0 0000000007eb3800 > 0000000007eed018 > [ 0.036000] Call Trace: > [ 0.036000] [<ffffffff810624f1>] efi_call5+0x71/0xf0 > [ 0.036000] [<ffffffff81061879>] ? virt_efi_set_variable+0x49/0x60 > [ 0.036000] [<ffffffff81d51d4c>] efi_enter_virtual_mode+0x2fe/0x332 > [ 0.036000] [<ffffffff81d34edc>] start_kernel+0x3a4/0x443 > [ 0.036000] [<ffffffff81d34941>] ? repair_env_string+0x5c/0x5c > [ 0.036000] [<ffffffff81d34120>] ? early_idt_handlers+0x120/0x120 > [ 0.036000] [<ffffffff81d345ee>] x86_64_start_reservations+0x2a/0x2c > [ 0.036000] [<ffffffff81d34733>] x86_64_start_kernel+0x143/0x152 > [ 0.036000] Code: Bad RIP value. > [ 0.036000] RIP [<fffffffefe60d64d>] 0xfffffffefe60d64d > [ 0.036000] RSP <ffffffff81c01d48> > [ 0.036000] CR2: fffffffefe60d64d > [ 0.036000] ---[ end trace acf85ef8d4475d7c ]---
Right. Therefore, even though my new patch series [PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe is on the list now, and your small patch above, applied on top, could enable the feature for OVMF, I'd like it to be disabled by default. There's a number of users employing OVMF with Windows 7 for GPU passthru, for example. A nice solution could be: - apply my series named above (well, obviously, whatever you want to do, you must commit my pending patches first! ;> ) - invent a new fw_cfg file name, and payload, that puts Gabriel's recent QEMU feature to use: 81b2b810 "fw_cfg: insert fw_cfg file blobs via qemu cmdline" Preferably, document this new file somewhere (outside of QEMU?) - in PlatformPei, check this fw_cfg file, and set PcdPropertiesTableEnable to TRUE dynamically. (Example: SmbiosVersionInitialization().) That would be early enough for the DXE core too see the fresh value. - Submit Ard's patch re 4K alignment in the linker script for real. Patches welcome. :) Thanks Laszlo ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
