From: Daniel Kiper <daniel.kiper@oracle.com>
To: hpa@zytor.com
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, bp@alien8.de, corbet@lwn.net,
dpsmith@apertussolutions.com, eric.snowberg@oracle.com,
kanth.ghatraju@oracle.com, konrad.wilk@oracle.com,
mingo@redhat.com, ross.philipson@oracle.com, tglx@linutronix.de
Subject: Re: [PATCH v2 2/3] x86/boot: Introduce the setup_indirect
Date: Tue, 1 Oct 2019 16:47:43 +0200 [thread overview]
Message-ID: <20191001144743.qrazs4fi7iuf25k5@tomti.i.net-space.pl> (raw)
In-Reply-To: <143DFBDE-E604-48E0-8072-6DB68E3E83C1@zytor.com>
On Fri, Jul 12, 2019 at 08:56:44AM -0700, hpa@zytor.com wrote:
> On July 4, 2019 9:36:11 AM PDT, Daniel Kiper <daniel.kiper@oracle.com> wrote:
[...]
> >diff --git a/arch/x86/include/uapi/asm/bootparam.h
> >b/arch/x86/include/uapi/asm/bootparam.h
> >index b05318112452..aaaa17fa6ad6 100644
> >--- a/arch/x86/include/uapi/asm/bootparam.h
> >+++ b/arch/x86/include/uapi/asm/bootparam.h
> >@@ -2,7 +2,7 @@
> > #ifndef _ASM_X86_BOOTPARAM_H
> > #define _ASM_X86_BOOTPARAM_H
> >
> >-/* setup_data types */
> >+/* setup_data/setup_indirect types */
> > #define SETUP_NONE 0
> > #define SETUP_E820_EXT 1
> > #define SETUP_DTB 2
> >@@ -10,6 +10,7 @@
> > #define SETUP_EFI 4
> > #define SETUP_APPLE_PROPERTIES 5
> > #define SETUP_JAILHOUSE 6
> >+#define SETUP_INDIRECT 7
> >
> > /* ram_size flags */
> > #define RAMDISK_IMAGE_START_MASK 0x07FF
> >@@ -47,6 +48,14 @@ struct setup_data {
> > __u8 data[0];
> > };
> >
> >+/* extensible setup indirect data node */
> >+struct setup_indirect {
> >+ __u32 type;
> >+ __u32 reserved; /* Reserved, must be set to zero. */
> >+ __u64 len;
> >+ __u64 addr;
> >+};
> >+
> > struct setup_header {
> > __u8 setup_sects;
> > __u16 root_flags;
>
> This needs actual implementation; we can't advertise it until the
> kernel knows how to consume the data! It probably should be moved to
> after the 3/3 patch.
>
> Implementing this has two parts:
>
> 1. The kernel needs to be augmented so it can find current objects via
> indirection.
>
> 2. And this is the main reason for this in the first place: the early
> code needs to walk the list and map out the memory areas which are
> occupied so it doesn't clobber anything; this allows this code to be
> generic as opposed to having to know what is a pointer and what size
> it might point to.
>
> (The decompressor didn't need this until kaslr entered the picture,
> but now it does, sadly.)
Do you think about arch/x86/boot/compressed/kaslr.c:mem_avoid[]?
But it is static. OK, we can assume that we do not accept more than
something indirect entries. However, this is not nice...
> Optional/future enhancements that might be nice:
>
> 3. Add some kind of description (e.g. foo=u64 ; bar=str ; baz=blob) to
> make it possible to write a bootloader that can load these kinds of
> objects without specific enabling.
This means an extension to command line parser. Am I right?
> 4. Add support for mapping initramfs fragments this way.
>
> 5. Add support for passingload-on-boot kernel modules.
I am not sure what you mean exactly by those two.
Anyway, I would focus only on things which are potentially useful now or
in the near future and not require much code changes. So, IMO #1 and #2
at this point.
Daniel
next prev parent reply other threads:[~2019-10-01 14:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-04 16:36 [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes Daniel Kiper
2019-07-04 16:36 ` [PATCH v2 1/3] x86/boot: Introduce the kernel_info Daniel Kiper
2019-07-12 16:04 ` hpa
2019-09-30 15:01 ` Daniel Kiper
2019-09-30 17:18 ` H. Peter Anvin
2019-10-01 11:41 ` Daniel Kiper
2019-10-01 22:28 ` H. Peter Anvin
2019-10-02 12:00 ` Daniel Kiper
2019-07-04 16:36 ` [PATCH v2 2/3] x86/boot: Introduce the setup_indirect Daniel Kiper
2019-07-12 15:56 ` hpa
2019-10-01 14:47 ` Daniel Kiper [this message]
2019-07-04 16:36 ` [PATCH v2 3/3] x86/boot: Introduce the kernel_info.setup_type_max Daniel Kiper
2019-07-12 15:59 ` hpa
2019-07-12 11:58 ` [PATCH v2 0/3] x86/boot: Introduce the kernel_info et consortes Daniel Kiper
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=20191001144743.qrazs4fi7iuf25k5@tomti.i.net-space.pl \
--to=daniel.kiper@oracle.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dpsmith@apertussolutions.com \
--cc=eric.snowberg@oracle.com \
--cc=hpa@zytor.com \
--cc=kanth.ghatraju@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=ross.philipson@oracle.com \
--cc=tglx@linutronix.de \
--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).