On Mon, 2 Mar 2020 at 00:03, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > On Sun, Mar 01, 2020 at 11:56:44PM +0100, Ard Biesheuvel wrote: > > On Sun, 1 Mar 2020 at 23:01, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > > > On Sun, Mar 01, 2020 at 10:36:05PM +0100, Ard Biesheuvel wrote: > > > > On Sun, 1 Mar 2020 at 21:54, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > > > 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 > > > > > > > > > > Right, but it's the last (highest) range in my memory map. It was just > > > to illustrate that I have no addresses above 4Gb, unlike the mapping you > > > got, although I now see that the MMIO range is the last one printed > > > regardless of where RAM ends, so that wasn't quite enough. I only get > > > the 4g-5g mapping range if I run it with -m 4096. > > > > > > This is the tail end of the mapping I got. > > > > > > [ 0.000000] efi: mem38: [Conventional Memory| | | | | | | | | |WB|WT|WC|UC] range=[0x00000000bfe00000-0x00000000bfe89fff] (0MB) > > > [ 0.000000] efi: mem39: [Boot Data | | | | | | | | | |WB|WT|WC|UC] range=[0x00000000bfe8a000-0x00000000bfea9fff] (0MB) > > > [ 0.000000] efi: mem40: [Boot Code | | | | | | | | | |WB|WT|WC|UC] range=[0x00000000bfeaa000-0x00000000bfeccfff] (0MB) > > > [ 0.000000] efi: mem41: [Boot Data | | | | | | | | | |WB|WT|WC|UC] range=[0x00000000bfecd000-0x00000000bfed5fff] (0MB) > > > [ 0.000000] efi: mem42: [Boot Code | | | | | | | | | |WB|WT|WC|UC] range=[0x00000000bfed6000-0x00000000bfef3fff] (0MB) > > > [ 0.000000] efi: mem43: [Runtime Data |RUN| | | | | | | | |WB|WT|WC|UC] range=[0x00000000bfef4000-0x00000000bff77fff] (0MB) > > > [ 0.000000] efi: mem44: [ACPI Memory NVS | | | | | | | | | |WB|WT|WC|UC] range=[0x00000000bff78000-0x00000000bfffffff] (0MB) > > > [ 0.000000] efi: mem45: [Memory Mapped I/O |RUN| | | | | | | | | | | |UC] range=[0x00000000ffc00000-0x00000000ffffffff] (4MB) > > > > Looks like it's the difference in machine type - I was using q35, and > > when I switch to the default, I can reproduce the early boot crash you > > sent the patch for. I don't see the other issue though. > > So you can boot successfully without hanging in SetVirtualAddressMap? > Weird. I'm using QEMU 4.2.0 in case that matters. Mine is 2.11, as shipped with my Ubuntu Bionic installation (company laptop)
