Cc'ing fastboot so more people benefit from this.
Phil Howard <[EMAIL PROTECTED]> writes:
> Thanks for the reply. I do have new questions. If I do achieve a full
> understanding of this, I'll write some documentation for it.
>
>
> On Wed, Oct 18, 2006 at 05:05:46AM -0600, Eric W. Biederman wrote:
>
> | So actually using sys_kexec_load to get something done may not be as simple
> as
> | you would like.
> |
> | The basic pieces are:
> |
> | struct kexec_segment {
> | void __user *buf;
> | size_t bufsz;
> | unsigned long mem; /* User space sees this as a (void *) ... */
> | size_t memsz;
> | };
> | long sys_kexec_load(unsigned long entry,
> | unsigned long nr_segments,
> | struct kexec_segment __user *segments,
> | unsigned long flags);
> |
> | followed by:
> | sys_reboot(LINUX_REBOOT_CMD_KEXEC);
> |
> |
> | All destination address passed to sys_kexec_load are machine physical
> address.
>
> Are these the addresses the have to be reserved in advance and is
> where the image contents is copied to during the call? Or are they
> just the addresses the contents get stored to later when the image
> is to be executed, and they get saved somewhere else in the interim?
The addresses the contents get stored to later when the image is to be
executed.
For the kexec on panic case the transfer case the copy actually happens
during the syscall, to a reserved region. So we have lower odds of
a broken kernel stomping it.
> | Each segment is a pair of a user space buffer plus the physical address it
> is
> | destined to go to. If the destination memory size is greater then the
> source
> memory
> | size the extra bytes are zero padded.
> |
> | Currently the destination addresses and sizes must be in page aligned
> | and in page sized chunks.
> |
> | entry is the physical address to jump to start the process.
> |
> | The processor operating mode is the same mode the kernel runs the
> | process in with virtual address identity mapped to physical address,
> | or with the MMU disabled.
>
> So if I wanted to start something that can only start in real mode,
> I'd need to load code that does that, or patch the kexec feature to
> do it (maybe an extra flag or architecture code).
Yes you would need code that switches modes. That code is already
in /sbin/kexec :)
> One of my concerns is getting the currently running system shutdown
> OK and then invoking the new kernel. It looks like I need to have
> the "kexec" program installed on the partition I'm going to have
> mounted R/O at that time, or copied into ramfs or tmpfs if I don't
> have a partition mounted. Then I would put "/sbin/kexec -e" in
> the /etc/inittab file in pace of "/sbin/reboot -f"?
Yes. I unfortunately never got a patch into /sbin/reboot.
/sbin/reboot -f is not recommended, for normal use.
The reason it is a two syscall sequence is so you can load the image
do a clean shutdown and then switch.
> | The kexec flags field is a little more complicated. In the normal
> | case just passing 0 should work.
> |
> | The upper 16 bites of the flags field specifies the architecture
> | the kernel is running on. This allows safely for things like
> | 32bit binaries on 64bit kernels to be used. As they tell kexec
> | yes I know my destination is 64bits. Passing zero only works
> | for non-compatibility mode applications.
>
> So if currently a 32 bit kernel is running on a 64 bit capable machine,
> what would passing 0 mean to it? Does this need to identify what the
> kernel I want to run is, or is it just identifying what I know the
> machine to be capable of?
It identifies the mode the kernel is currently operating in.
0 just means the user space and the kernel are in the same mode.
Several architectures have restrictions like the ability
to only run 64bit kernels, but they support a 32bit userspace.
> | Of the lower 16bits only two values have been defined.
> | 0 - A normal kexec image is being loaded.
> | 1 - A kexec on panic image is being loaded.
> |
> | What to load is left up to user space.
> | Good Luck,
>
> Thanks.
>
> What I am wanting to set up is a network based system starter.
> But this isn't a netboot. Instead, when the machine reboots,
> it starts up network access including sshd, and waits for someone
> authorized to connect and make the reboot selection within the
> wait window (probably 3 minutes), and loads a default if that
> does not happen (if configured for a default). Previously I
> would have to juggle boot images around, and make each system
> that could be started be smart enough to juggle the boot images
> back to run the startup selector. I think with kexec, I just
> need set up a small linux partition and a minimal kernel with
> the kexec call enabled, and make it be, and stay, the normal
> loaded kernel. Then the other kernels can be somewhere the
> program can find.
Yep that sounds correct.
Eric
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
