On Sun, 1 Mar 2020 at 21:54, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > On Sun, Mar 01, 2020 at 09:41:33PM +0100, Ard Biesheuvel wrote: > > On Sun, 1 Mar 2020 at 21:20, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > On Sun, 1 Mar 2020 at 21:02, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > > > On Sun, 1 Mar 2020 at 21:00, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > > > > > > > On Sun, Mar 01, 2020 at 08:36:42PM +0100, Ard Biesheuvel wrote: > > > > > > On Sun, 1 Mar 2020 at 18:22, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > On Sun, Mar 01, 2020 at 12:15:10PM -0500, Arvind Sankar wrote: > > > > > > > > What I'm doing is creating an x86-64 defconfig based on tip:efi/core, > > > > > > > > and then running it via > > > > > > > > > > > > > > > > $ qemu-system-x86_64 -cpu Haswell -pflash qemu/OVMF_64.fd \ > > > > > > > ^^^^^^^ > > > > > > > That OVMF_64.fd is incorrect copy/paste from a different run, the panic > > > > > > > case is using OVMF-mixed-mode-compat-section.fd. > > > > > > > > -drive file=fat:rw:qemu/boot -nographic -m 3072 > > > > > > > > > > > > Thanks for the patch. Interestingly, I don't even make it to the point > > > > > > where it crashes, and I end up in an ASSERT() in the firmware: > > > > > > > > > > > > ASSERT_EFI_ERROR (Status = Not Found) > > > > > > ASSERT /home/ardbie01/build/edk2/MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.c(347): > > > > > > !EFI_ERROR (Status) > > > > > > > > > > > > which appears to be a result of the fact that the memory map passed to > > > > > > SetVirtualAddressMap() does not cover some function pointer that gets > > > > > > converted in that code. > > > > > > > > > > > > I don't remember - does mixed mode even work in general with 3 GB of memory? > > > > > > > > > > Oh -- is there some option to enable debugging assertions? I did see > > > > > that it crashed somewhere inside SetVirtualMap (i.e. we called it and > > > > > it never returned). > > > > > > > > > > > > > The ASSERT()s are always active, but you don't see them if you don't > > > > expose the debugcon > > > > > > > > > For some reason, with nokaslr on the command line, I can't get this to > > > > > crash. All the addresses seem to be within 4Gb, so it ought to work, no? > > > > > > > > The issue is in the memory map we compile and send back to the firware > > > > - apparently, that ends up wrong for some reason. > > > > > > BTW I uploaded another version which uses Loadimage/Startimage (and > > > the .compat section) for mixed mode kernels passed to QEMU via the > > > command line > > > > > > https://people.linaro.org/~ard.biesheuvel/OVMF-mixed-mode-compat-section-cmdline.fd > > > > I see this in the memory map > > > > [ 0.000000] efi: mem47: [Conventional Memory| | | | | | | | > > | |WB|WT|WC|UC] range=[0x0000000100000000-0x000000013fffffff] > > (1024MB) > > > > so it looks like qemu-system-x86_64 puts the memory in a weird place? > > Or is this expected? > > Mine ended here: > [ 0.000000] efi: mem45: [Memory Mapped I/O |RUN| | | | | | | | | | | |UC] range=[0x00000000ffc00000-0x00000000ffffffff] (4MB) > are you running with -m 3072 or more? > That is not memory, it's some mmio region > If you get memory mapped above 4Gb you will almost certainly crash in > the call to SetVirtualMemoryMap, but that's usually because the memmap > you pass in is above 4Gb and can't be accessed by the firmware at all.
