From: Matt Fleming <matt@codeblueprint.co.uk>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Omar Sandoval <osandov@osandov.com>,
Dave Young <dyoung@redhat.com>,
kernel-team@fb.com
Subject: Re: kexec regression since 4.9 caused by efi
Date: Thu, 16 Mar 2017 12:15:32 +0000 [thread overview]
Message-ID: <20170316121532.GE6261@codeblueprint.co.uk> (raw)
In-Reply-To: <CAKv+Gu-gRmt=Vq=QCcT5ETY9DwLzJe0f4gHR_9sFMKX7-vK++w@mail.gmail.com>
On Thu, 09 Mar, at 12:53:36PM, Ard Biesheuvel wrote:
>
> Hi Omar,
>
> Thanks for tracking this down.
>
> I wonder if this is an unintended side effect of the way we repurpose
> the EFI_MEMORY_RUNTIME attribute in efi_arch_mem_reserve(). AFAIUI,
> splitting memory map entries should only be necessary for regions that
> are not runtime memory regions to begin with, and so whether their
> virtual mapping address makes sense or not should be irrelevant.
>
> Perhaps this only illustrates my lack of understanding of the x86 way
> of doing this, so perhaps Matt can shed some light on this?
Sorry for the delay.
Yes, Ard is correct. It's not necessary to split/reserve memory
regions that already have the EFI_MEMORY_RUNTIME attribute.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Omar Sandoval <osandov@osandov.com>,
Dave Young <dyoung@redhat.com>, Ingo Molnar <mingo@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
kernel-team@fb.com,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>
Subject: Re: kexec regression since 4.9 caused by efi
Date: Thu, 16 Mar 2017 12:15:32 +0000 [thread overview]
Message-ID: <20170316121532.GE6261@codeblueprint.co.uk> (raw)
In-Reply-To: <CAKv+Gu-gRmt=Vq=QCcT5ETY9DwLzJe0f4gHR_9sFMKX7-vK++w@mail.gmail.com>
On Thu, 09 Mar, at 12:53:36PM, Ard Biesheuvel wrote:
>
> Hi Omar,
>
> Thanks for tracking this down.
>
> I wonder if this is an unintended side effect of the way we repurpose
> the EFI_MEMORY_RUNTIME attribute in efi_arch_mem_reserve(). AFAIUI,
> splitting memory map entries should only be necessary for regions that
> are not runtime memory regions to begin with, and so whether their
> virtual mapping address makes sense or not should be irrelevant.
>
> Perhaps this only illustrates my lack of understanding of the x86 way
> of doing this, so perhaps Matt can shed some light on this?
Sorry for the delay.
Yes, Ard is correct. It's not necessary to split/reserve memory
regions that already have the EFI_MEMORY_RUNTIME attribute.
next prev parent reply other threads:[~2017-03-16 12:16 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-08 20:16 kexec regression since 4.9 caused by efi Omar Sandoval
2017-03-09 2:21 ` Dave Young
2017-03-09 3:36 ` Omar Sandoval
2017-03-09 6:38 ` Dave Young
2017-03-09 6:38 ` Dave Young
2017-03-09 6:38 ` Dave Young
2017-03-09 9:54 ` Omar Sandoval
2017-03-09 9:54 ` Omar Sandoval
2017-03-09 11:53 ` Ard Biesheuvel
2017-03-09 11:53 ` Ard Biesheuvel
2017-03-09 11:53 ` Ard Biesheuvel
2017-03-10 1:39 ` Dave Young
2017-03-10 1:39 ` Dave Young
2017-03-16 12:15 ` Matt Fleming [this message]
2017-03-16 12:15 ` Matt Fleming
2017-03-10 1:42 ` Dave Young
2017-03-10 1:42 ` Dave Young
2017-03-10 1:42 ` Dave Young
2017-03-13 7:37 ` Dave Young
2017-03-13 7:37 ` Dave Young
2017-03-13 7:37 ` Dave Young
2017-03-16 12:41 ` Matt Fleming
2017-03-16 12:41 ` Matt Fleming
2017-03-16 12:41 ` Matt Fleming
2017-03-16 17:50 ` Omar Sandoval
2017-03-16 17:50 ` Omar Sandoval
2017-04-03 23:54 ` Omar Sandoval
2017-04-03 23:54 ` Omar Sandoval
2017-04-03 23:54 ` Omar Sandoval
2017-03-17 2:09 ` Dave Young
2017-03-17 2:09 ` Dave Young
2017-03-17 2:09 ` Dave Young
2017-03-17 13:25 ` Ard Biesheuvel
2017-03-17 13:25 ` Ard Biesheuvel
2017-03-17 13:25 ` Ard Biesheuvel
2017-03-17 13:32 ` Matt Fleming
2017-03-17 13:32 ` Matt Fleming
2017-03-17 13:32 ` Matt Fleming
2017-03-20 2:14 ` Dave Young
2017-03-20 2:14 ` Dave Young
2017-03-20 2:14 ` Dave Young
2017-03-21 7:48 ` Dave Young
2017-03-21 7:48 ` Dave Young
2017-03-21 7:48 ` Dave Young
2017-03-22 16:10 ` Ard Biesheuvel
2017-03-22 16:10 ` Ard Biesheuvel
2017-03-22 16:10 ` Ard Biesheuvel
2017-03-23 2:43 ` Dave Young
2017-03-23 2:43 ` Dave Young
2017-03-23 2:43 ` Dave Young
2017-04-04 13:37 ` Matt Fleming
2017-04-04 13:37 ` Matt Fleming
2017-04-04 13:37 ` Matt Fleming
2017-04-05 1:23 ` Dave Young
2017-04-05 1:23 ` Dave Young
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=20170316121532.GE6261@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=ard.biesheuvel@linaro.org \
--cc=dyoung@redhat.com \
--cc=kernel-team@fb.com \
--cc=kexec@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=osandov@osandov.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.