From: Arvind Sankar <nivedita@alum.mit.edu>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
linux-efi <linux-efi@vger.kernel.org>,
Hans de Goede <hdegoede@redhat.com>,
the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [PATCH v3 0/6] efi/x86: add support for generic EFI mixed mode boot
Date: Sun, 1 Mar 2020 18:03:46 -0500 [thread overview]
Message-ID: <20200301230345.GA2227739@rani.riverdale.lan> (raw)
In-Reply-To: <CAKv+Gu-zqrPSwgFAsamPQzwB_uVv8UaLZyqhOsBPb_m=FccnKg@mail.gmail.com>
On Sun, Mar 01, 2020 at 11:56:44PM +0100, Ard Biesheuvel wrote:
> On Sun, 1 Mar 2020 at 23:01, Arvind Sankar <nivedita@alum.mit.edu> 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@alum.mit.edu> 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.
next prev parent reply other threads:[~2020-03-01 23:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-22 15:55 [PATCH v3 0/6] efi/x86: add support for generic EFI mixed mode boot Ard Biesheuvel
2020-02-22 15:55 ` [PATCH v3 1/6] efi/x86: add headroom to decompressor BSS to account for setup block Ard Biesheuvel
2020-02-22 15:55 ` [PATCH v3 2/6] efi/x86: Drop redundant .bss section Ard Biesheuvel
2020-02-22 15:55 ` [PATCH v3 3/6] efi/libstub/x86: Make loaded_image protocol handling mixed mode safe Ard Biesheuvel
2020-02-22 15:55 ` [PATCH v3 4/6] efi/libstub/x86: Use Exit() boot service to exit the stub on errors Ard Biesheuvel
2020-02-22 15:55 ` [PATCH v3 5/6] efi/x86: Implement mixed mode boot without the handover protocol Ard Biesheuvel
2020-02-22 15:55 ` [PATCH v3 6/6] efi/x86: Add true mixed mode entry point into .compat section Ard Biesheuvel
2020-03-01 17:15 ` [PATCH v3 0/6] efi/x86: add support for generic EFI mixed mode boot Arvind Sankar
2020-03-01 17:22 ` Arvind Sankar
2020-03-01 19:36 ` Ard Biesheuvel
2020-03-01 20:00 ` Arvind Sankar
2020-03-01 20:02 ` Ard Biesheuvel
2020-03-01 20:20 ` Ard Biesheuvel
2020-03-01 20:41 ` Ard Biesheuvel
2020-03-01 20:54 ` Arvind Sankar
2020-03-01 21:36 ` Ard Biesheuvel
2020-03-01 22:01 ` Arvind Sankar
2020-03-01 22:56 ` Ard Biesheuvel
2020-03-01 23:03 ` Arvind Sankar [this message]
2020-03-02 12:14 ` Ard Biesheuvel
2020-03-03 4:19 ` Arvind Sankar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200301230345.GA2227739@rani.riverdale.lan \
--to=nivedita@alum.mit.edu \
--cc=ardb@kernel.org \
--cc=hdegoede@redhat.com \
--cc=linux-efi@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).