From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Dave Young <dyoung@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org, bhe@redhat.com,
kexec@lists.infradead.org, will.deacon@arm.com,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
catalin.marinas@arm.com,
Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org, vgoyal@redhat.com
Subject: Re: [RFC] arm64: kexec_file_load support
Date: Tue, 5 Jul 2016 17:03:57 +0900 [thread overview]
Message-ID: <20160705080355.GQ20774@linaro.org> (raw)
In-Reply-To: <20160705012556.GC8190@dhcp-128-65.nay.redhat.com>
Hi Dave,
On Tue, Jul 05, 2016 at 09:25:56AM +0800, Dave Young wrote:
> On 07/04/16 at 03:58pm, AKASHI Takahiro wrote:
> > Hi,
> >
> > On Fri, Jul 01, 2016 at 12:46:31PM -0300, Thiago Jung Bauermann wrote:
> > > Am Freitag, 01 Juli 2016, 14:11:12 schrieb AKASHI Takahiro:
> > > > I'm not sure whether there is any demand for kexec_file_load
> > > > support on arm64, but anyhow I'm working on this and now
> > > > my early prototype code does work fine.
> > >
> > > It is necessary if you want to support loading only signed kernels, and also
> > > if you want IMA to measure the kernel in its event log.
> > >
> > > > There is, however, one essential issue:
> > > > While arm64 kernel requires a device tree blob to be set up
> > > > correctly at boot time, the current system call API doesn't
> > > > have this parameter.
> > > > int kexec_file_load(int kernel_fd, int initrd_fd,
> > > > unsigned long cmdline_len, const char
> > > > *cmdline_ptr, unsigned long flags);
> > > >
> > > > Should we invent a new system call, like kexec_file_load2,
> > > > and, if so, what kind of interface would be desired?
> > >
> > > I'm facing the same issue on powerpc. What I'm doing is taking the device
> > > tree that was used to boot the current kernel and modifying it as necessary
> > > to pass it to the next kernel.
> >
> > That is exactly what I do.
> >
> > > I agree that it would be better if we could have a system call where a
> > > custom device tree could be passed. One suggestion is:
> >
> > For powerpc, you might be able to use dtbImage instead of Image
> > without changing the kernel interfaces.
> > >
> > > kexec_file_load2(int fds[], int fd_types[], int nr_fds,
> > > unsigned long cmdline_len, const char *cmdline_ptr,
> > > unsigned long flags);
> >
> > You don't want to simply add one more argument, i.e. dtb_fd, don't you.
> >
> > I prefer a slightly-simpler interface:
> > struct kexec_file_fd {
> > enum kexec_file_type;
> > int fd;
> > }
> >
> > int kexec_file_load2(struct kexec_file_fd[], int nr_fds, int flags);
> >
> > Or if you want to keep the compatibility with the existing system call,
> >
> > int kexec_file_load(int kernel_fd, int initrd_fd,
> > unsigned long cmdline_len, const char *cmdline_ptr,
> > unsigned long flags,
> > int struct kexec_file_fd[], int nr_fds);
> >
> > Here SYSCALL_DEFINE7() have to be defined, and I'm not sure that we will not
> > have a problem in adding a system call with more than 6 arguments.
> >
> > > Where fds is an array with nr_fds file descriptors and fd_types is an array
> > > specifying what each fd in fds is. So for example, if fds[i] is the kernel,
> > > then fd_types[i] would have the value KEXEC_FILE_KERNEL_FD. If fds[i] is the
> > > device tree blob, fd_types[i], would have the value KEXEC_FILE_DTB and so
> > > on. That way, the syscall can be extended for an arbitrary number and types
> > > of segments that have to be loaded, just like kexec_load.
> > >
> > > Another option is to have a struct:
> > >
> > > kexec_file_load2(struct kexec_file_params *params, unsigned long params_sz);
> >
> > Wow, we can add any number of new parameters with this interface.
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > > Where:
> > >
> > > struct kexec_file_params {
> > > int version; /* allows struct to be extended in the future */
> > > int fds[];
> > > int fd_types[];
> > > int nr_fds;
> > > unsigned long cmdline_len;
> > > const char *cmdline_ptr;
> > > unsigned long flags;
> > > };
> > >
> > > This is even more flexible.
>
> I would like to vote for this one, and use kexec_file_fd fds[] in the struct
If we take this approach, we'd better take "flags" out of struct,
and my preference would be:
enum kexec_file_type {
KEXEC_FILE_TYPE_KERNEL;
KEXEC_FILE_TYPE_INITRD;
KEXEC_FILE_TYPE_DTB;
}
struct kexec_file_fd {
enum kexec_file_type;
int fd;
}
sturct kexec_file_params {
int version;
unsigned char *cmdline;
unsigned long cmdline_len;
int nr_fds;
struct kexec_file_fd fds[0];
}
int kexec_file_load2(int kernel_fd, unsigned long flags,
sturct kexec_file_params extra);
So we don't have to retrieve extra if KEXEC_FILE_UNLOAD
(or kernel_fd < 0?),
and only once retrieve extra if extra != NULL && nr_fds == 0.
Thanks,
-Takahiro AKASHI
> Thanks
> Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Dave Young <dyoung@redhat.com>
Cc: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>,
kexec@lists.infradead.org, ebiederm@xmission.com, bhe@redhat.com,
vgoyal@redhat.com, will.deacon@arm.com, catalin.marinas@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC] arm64: kexec_file_load support
Date: Tue, 5 Jul 2016 17:03:57 +0900 [thread overview]
Message-ID: <20160705080355.GQ20774@linaro.org> (raw)
In-Reply-To: <20160705012556.GC8190@dhcp-128-65.nay.redhat.com>
Hi Dave,
On Tue, Jul 05, 2016 at 09:25:56AM +0800, Dave Young wrote:
> On 07/04/16 at 03:58pm, AKASHI Takahiro wrote:
> > Hi,
> >
> > On Fri, Jul 01, 2016 at 12:46:31PM -0300, Thiago Jung Bauermann wrote:
> > > Am Freitag, 01 Juli 2016, 14:11:12 schrieb AKASHI Takahiro:
> > > > I'm not sure whether there is any demand for kexec_file_load
> > > > support on arm64, but anyhow I'm working on this and now
> > > > my early prototype code does work fine.
> > >
> > > It is necessary if you want to support loading only signed kernels, and also
> > > if you want IMA to measure the kernel in its event log.
> > >
> > > > There is, however, one essential issue:
> > > > While arm64 kernel requires a device tree blob to be set up
> > > > correctly at boot time, the current system call API doesn't
> > > > have this parameter.
> > > > int kexec_file_load(int kernel_fd, int initrd_fd,
> > > > unsigned long cmdline_len, const char
> > > > *cmdline_ptr, unsigned long flags);
> > > >
> > > > Should we invent a new system call, like kexec_file_load2,
> > > > and, if so, what kind of interface would be desired?
> > >
> > > I'm facing the same issue on powerpc. What I'm doing is taking the device
> > > tree that was used to boot the current kernel and modifying it as necessary
> > > to pass it to the next kernel.
> >
> > That is exactly what I do.
> >
> > > I agree that it would be better if we could have a system call where a
> > > custom device tree could be passed. One suggestion is:
> >
> > For powerpc, you might be able to use dtbImage instead of Image
> > without changing the kernel interfaces.
> > >
> > > kexec_file_load2(int fds[], int fd_types[], int nr_fds,
> > > unsigned long cmdline_len, const char *cmdline_ptr,
> > > unsigned long flags);
> >
> > You don't want to simply add one more argument, i.e. dtb_fd, don't you.
> >
> > I prefer a slightly-simpler interface:
> > struct kexec_file_fd {
> > enum kexec_file_type;
> > int fd;
> > }
> >
> > int kexec_file_load2(struct kexec_file_fd[], int nr_fds, int flags);
> >
> > Or if you want to keep the compatibility with the existing system call,
> >
> > int kexec_file_load(int kernel_fd, int initrd_fd,
> > unsigned long cmdline_len, const char *cmdline_ptr,
> > unsigned long flags,
> > int struct kexec_file_fd[], int nr_fds);
> >
> > Here SYSCALL_DEFINE7() have to be defined, and I'm not sure that we will not
> > have a problem in adding a system call with more than 6 arguments.
> >
> > > Where fds is an array with nr_fds file descriptors and fd_types is an array
> > > specifying what each fd in fds is. So for example, if fds[i] is the kernel,
> > > then fd_types[i] would have the value KEXEC_FILE_KERNEL_FD. If fds[i] is the
> > > device tree blob, fd_types[i], would have the value KEXEC_FILE_DTB and so
> > > on. That way, the syscall can be extended for an arbitrary number and types
> > > of segments that have to be loaded, just like kexec_load.
> > >
> > > Another option is to have a struct:
> > >
> > > kexec_file_load2(struct kexec_file_params *params, unsigned long params_sz);
> >
> > Wow, we can add any number of new parameters with this interface.
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > > Where:
> > >
> > > struct kexec_file_params {
> > > int version; /* allows struct to be extended in the future */
> > > int fds[];
> > > int fd_types[];
> > > int nr_fds;
> > > unsigned long cmdline_len;
> > > const char *cmdline_ptr;
> > > unsigned long flags;
> > > };
> > >
> > > This is even more flexible.
>
> I would like to vote for this one, and use kexec_file_fd fds[] in the struct
If we take this approach, we'd better take "flags" out of struct,
and my preference would be:
enum kexec_file_type {
KEXEC_FILE_TYPE_KERNEL;
KEXEC_FILE_TYPE_INITRD;
KEXEC_FILE_TYPE_DTB;
}
struct kexec_file_fd {
enum kexec_file_type;
int fd;
}
sturct kexec_file_params {
int version;
unsigned char *cmdline;
unsigned long cmdline_len;
int nr_fds;
struct kexec_file_fd fds[0];
}
int kexec_file_load2(int kernel_fd, unsigned long flags,
sturct kexec_file_params extra);
So we don't have to retrieve extra if KEXEC_FILE_UNLOAD
(or kernel_fd < 0?),
and only once retrieve extra if extra != NULL && nr_fds == 0.
Thanks,
-Takahiro AKASHI
> Thanks
> Dave
WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] arm64: kexec_file_load support
Date: Tue, 5 Jul 2016 17:03:57 +0900 [thread overview]
Message-ID: <20160705080355.GQ20774@linaro.org> (raw)
In-Reply-To: <20160705012556.GC8190@dhcp-128-65.nay.redhat.com>
Hi Dave,
On Tue, Jul 05, 2016 at 09:25:56AM +0800, Dave Young wrote:
> On 07/04/16 at 03:58pm, AKASHI Takahiro wrote:
> > Hi,
> >
> > On Fri, Jul 01, 2016 at 12:46:31PM -0300, Thiago Jung Bauermann wrote:
> > > Am Freitag, 01 Juli 2016, 14:11:12 schrieb AKASHI Takahiro:
> > > > I'm not sure whether there is any demand for kexec_file_load
> > > > support on arm64, but anyhow I'm working on this and now
> > > > my early prototype code does work fine.
> > >
> > > It is necessary if you want to support loading only signed kernels, and also
> > > if you want IMA to measure the kernel in its event log.
> > >
> > > > There is, however, one essential issue:
> > > > While arm64 kernel requires a device tree blob to be set up
> > > > correctly at boot time, the current system call API doesn't
> > > > have this parameter.
> > > > int kexec_file_load(int kernel_fd, int initrd_fd,
> > > > unsigned long cmdline_len, const char
> > > > *cmdline_ptr, unsigned long flags);
> > > >
> > > > Should we invent a new system call, like kexec_file_load2,
> > > > and, if so, what kind of interface would be desired?
> > >
> > > I'm facing the same issue on powerpc. What I'm doing is taking the device
> > > tree that was used to boot the current kernel and modifying it as necessary
> > > to pass it to the next kernel.
> >
> > That is exactly what I do.
> >
> > > I agree that it would be better if we could have a system call where a
> > > custom device tree could be passed. One suggestion is:
> >
> > For powerpc, you might be able to use dtbImage instead of Image
> > without changing the kernel interfaces.
> > >
> > > kexec_file_load2(int fds[], int fd_types[], int nr_fds,
> > > unsigned long cmdline_len, const char *cmdline_ptr,
> > > unsigned long flags);
> >
> > You don't want to simply add one more argument, i.e. dtb_fd, don't you.
> >
> > I prefer a slightly-simpler interface:
> > struct kexec_file_fd {
> > enum kexec_file_type;
> > int fd;
> > }
> >
> > int kexec_file_load2(struct kexec_file_fd[], int nr_fds, int flags);
> >
> > Or if you want to keep the compatibility with the existing system call,
> >
> > int kexec_file_load(int kernel_fd, int initrd_fd,
> > unsigned long cmdline_len, const char *cmdline_ptr,
> > unsigned long flags,
> > int struct kexec_file_fd[], int nr_fds);
> >
> > Here SYSCALL_DEFINE7() have to be defined, and I'm not sure that we will not
> > have a problem in adding a system call with more than 6 arguments.
> >
> > > Where fds is an array with nr_fds file descriptors and fd_types is an array
> > > specifying what each fd in fds is. So for example, if fds[i] is the kernel,
> > > then fd_types[i] would have the value KEXEC_FILE_KERNEL_FD. If fds[i] is the
> > > device tree blob, fd_types[i], would have the value KEXEC_FILE_DTB and so
> > > on. That way, the syscall can be extended for an arbitrary number and types
> > > of segments that have to be loaded, just like kexec_load.
> > >
> > > Another option is to have a struct:
> > >
> > > kexec_file_load2(struct kexec_file_params *params, unsigned long params_sz);
> >
> > Wow, we can add any number of new parameters with this interface.
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > > Where:
> > >
> > > struct kexec_file_params {
> > > int version; /* allows struct to be extended in the future */
> > > int fds[];
> > > int fd_types[];
> > > int nr_fds;
> > > unsigned long cmdline_len;
> > > const char *cmdline_ptr;
> > > unsigned long flags;
> > > };
> > >
> > > This is even more flexible.
>
> I would like to vote for this one, and use kexec_file_fd fds[] in the struct
If we take this approach, we'd better take "flags" out of struct,
and my preference would be:
enum kexec_file_type {
KEXEC_FILE_TYPE_KERNEL;
KEXEC_FILE_TYPE_INITRD;
KEXEC_FILE_TYPE_DTB;
}
struct kexec_file_fd {
enum kexec_file_type;
int fd;
}
sturct kexec_file_params {
int version;
unsigned char *cmdline;
unsigned long cmdline_len;
int nr_fds;
struct kexec_file_fd fds[0];
}
int kexec_file_load2(int kernel_fd, unsigned long flags,
sturct kexec_file_params extra);
So we don't have to retrieve extra if KEXEC_FILE_UNLOAD
(or kernel_fd < 0?),
and only once retrieve extra if extra != NULL && nr_fds == 0.
Thanks,
-Takahiro AKASHI
> Thanks
> Dave
next prev parent reply other threads:[~2016-07-05 7:58 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-01 5:11 [RFC] arm64: kexec_file_load support AKASHI Takahiro
2016-07-01 5:11 ` AKASHI Takahiro
2016-07-01 5:11 ` AKASHI Takahiro
2016-07-01 15:46 ` Thiago Jung Bauermann
2016-07-01 15:46 ` Thiago Jung Bauermann
2016-07-01 15:46 ` Thiago Jung Bauermann
2016-07-04 6:58 ` AKASHI Takahiro
2016-07-04 6:58 ` AKASHI Takahiro
2016-07-04 6:58 ` AKASHI Takahiro
2016-07-04 22:50 ` Thiago Jung Bauermann
2016-07-04 22:50 ` Thiago Jung Bauermann
2016-07-04 22:50 ` Thiago Jung Bauermann
2016-07-05 8:07 ` AKASHI Takahiro
2016-07-05 8:07 ` AKASHI Takahiro
2016-07-05 8:07 ` AKASHI Takahiro
2016-07-05 1:25 ` Dave Young
2016-07-05 1:25 ` Dave Young
2016-07-05 1:25 ` Dave Young
2016-07-05 8:03 ` AKASHI Takahiro [this message]
2016-07-05 8:03 ` AKASHI Takahiro
2016-07-05 8:03 ` AKASHI Takahiro
2016-07-07 6:12 ` Dave Young
2016-07-07 6:12 ` Dave Young
2016-07-07 6:12 ` Dave Young
2016-07-08 14:48 ` Thiago Jung Bauermann
2016-07-08 14:48 ` Thiago Jung Bauermann
2016-07-08 14:48 ` Thiago Jung Bauermann
2016-07-11 3:10 ` Dave Young
2016-07-11 3:10 ` Dave Young
2016-07-11 3:10 ` Dave Young
2016-07-11 7:19 ` AKASHI Takahiro
2016-07-11 7:19 ` AKASHI Takahiro
2016-07-11 7:19 ` AKASHI Takahiro
2016-07-11 8:14 ` Dave Young
2016-07-11 8:14 ` Dave Young
2016-07-11 8:14 ` 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=20160705080355.GQ20774@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=bauerman@linux.vnet.ibm.com \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=vgoyal@redhat.com \
--cc=will.deacon@arm.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.