should kernel image destination address be picked up by kernel itself?

should kernel image destination address be picked up by kernel itself?

[Ming Lei]

As I understand the code, current destination address is picked up by
either the user(elf image) or kexec-tools. It is not automatic, can we
let linux kernel choose the address instead? It is automatic and no way
to wipe out something important.

Thanks
Ming


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: should kernel image destination address be picked up by kernel itself?

[Eric W. Biederman]

"Ming Lei" <mlei@Brocade.COM> writes:

> As I understand the code, current destination address is picked up by
> either the user(elf image) or kexec-tools. It is not automatic, can we
> let linux kernel choose the address instead? It is automatic and no way
> to wipe out something important.

I don't follow.  The basic model of kexec is:

- kexec is fed a standalone executables (things that run without OS
  support)

- All of the policy decisions are made in user space (such as where to
  execute from)

- standalone executables are loaded into an address space where
  physical address and virtual address are the same.

- Sophisticated page swapping happens in the kernel where
  sys_kexec_load was called so that any valid address on the machine
  is available to the standalone executable.

What problem do you see in that model?
Why is it a problem for you?

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: should kernel image destination address be picked up by kernel itself?

[Ming Lei]

Hi Eric,

I tried run latest kexec-tools v2.0 on ppc freescale 85xx platforms.

>- All of the policy decisions are made in user space (such as where to
>  execute from)
Is where to execute from the physical address or the virtual address?
How do we know it is available to kexec, it may be taken.

>- standalone executables are loaded into an address space where
>  physical address and virtual address are the same.
There may be case that physical address and virtual address not the same
on linux, such as vmalloc.

>What problem do you see in that model?
>Why is it a problem for you?

Can we put something like -1 to indicate to kernel that user space wants
kernel to choose the virtual address to load the standalone executable,
then linux kernel can kmalloc this area and then load the standalone
executable.

Thanks
Ming

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: should kernel image destination address be picked up by kernel itself?

[Eric W. Biederman]

"Ming Lei" <mlei@Brocade.COM> writes:

> Hi Eric,
>
> I tried run latest kexec-tools v2.0 on ppc freescale 85xx platforms.
>
>>- All of the policy decisions are made in user space (such as where to
>>  execute from)
> Is where to execute from the physical address or the virtual address?
> How do we know it is available to kexec, it may be taken.

It should be physical and there should be an API in linux like
/proc/iomem which will report which addresses are memory.  ppc
is a little different than x86 so I'm not up to speed on how it
reports things.  I think it is with the device tree.

>>- standalone executables are loaded into an address space where
>>  physical address and virtual address are the same.
> There may be case that physical address and virtual address not the same
> on linux, such as vmalloc.

In the environment that kexec exports there should not be any.

>>What problem do you see in that model?
>>Why is it a problem for you?
>
> Can we put something like -1 to indicate to kernel that user space wants
> kernel to choose the virtual address to load the standalone executable,
> then linux kernel can kmalloc this area and then load the standalone
> executable.

You can do something like create a proper static ET_DYN executable and then 
/sbin/kexec will look for an address and load it there.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: should kernel image destination address be picked up by kernel itself?

[Ming Lei]

Hi Eric,

Do you know what's this purgatory directory for? I saw it is linked with
kexec in a weird way.

Another note for current code base is that there is merged directory
arch/powerpc since linux kernel 2.6.23, but kexec-tools still has ppc
and ppc64 separated. Is there anyone working on this merged arch?

Thanks
Ming


-----Original Message-----
From: Eric W. Biederman [mailto:ebiederm@xmission.com] 
Sent: Tuesday, February 03, 2009 1:43 PM
To: Ming Lei
Cc: kexec@lists.infradead.org
Subject: Re: should kernel image destination address be picked up by
kernel itself?

"Ming Lei" <mlei@Brocade.COM> writes:

> Hi Eric,
>
> I tried run latest kexec-tools v2.0 on ppc freescale 85xx platforms.
>
>>- All of the policy decisions are made in user space (such as where to
>>  execute from)
> Is where to execute from the physical address or the virtual address?
> How do we know it is available to kexec, it may be taken.

It should be physical and there should be an API in linux like
/proc/iomem which will report which addresses are memory.  ppc
is a little different than x86 so I'm not up to speed on how it
reports things.  I think it is with the device tree.

>>- standalone executables are loaded into an address space where
>>  physical address and virtual address are the same.
> There may be case that physical address and virtual address not the
same
> on linux, such as vmalloc.

In the environment that kexec exports there should not be any.

>>What problem do you see in that model?
>>Why is it a problem for you?
>
> Can we put something like -1 to indicate to kernel that user space
wants
> kernel to choose the virtual address to load the standalone
executable,
> then linux kernel can kmalloc this area and then load the standalone
> executable.

You can do something like create a proper static ET_DYN executable and
then 
/sbin/kexec will look for an address and load it there.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: should kernel image destination address be picked up by kernel itself?

[Eric W. Biederman]

"Ming Lei" <mlei@Brocade.COM> writes:

> Hi Eric,
>
> Do you know what's this purgatory directory for? I saw it is linked with
> kexec in a weird way.

Yep.  That is the relocatable code that run between one kernel and the next.

> Another note for current code base is that there is merged directory
> arch/powerpc since linux kernel 2.6.23, but kexec-tools still has ppc
> and ppc64 separated. Is there anyone working on this merged arch?

Userspace should not be affected by a kernel implementation detail
like that.

Eric


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: should kernel image destination address be picked up by kernel itself?

[Ming Lei]

>> "Ming Lei" <mlei@Brocade.COM> writes:
>>
>> Hi Eric,
>>
>> Do you know what's this purgatory directory for? I saw it is linked
with
>> kexec in a weird way.

>Yep.  That is the relocatable code that run between one kernel and the
next.

Is there any doc or email thread explain this purgatory and its purpose?

>> Another note for current code base is that there is merged directory
>> arch/powerpc since linux kernel 2.6.23, but kexec-tools still has ppc
>> and ppc64 separated. Is there anyone working on this merged arch?

>Userspace should not be affected by a kernel implementation detail
>like that.

Now linux kernel uses arch/powerpc to have both ppc32 and ppc64 code
together. Should I use arch/ppc in kexec-tools, then it wont work with
kernel powerpc since it uses device tree blob; if I use arch/ppc64 in
kexec-tools, then since I need to use for ppc32, it wont work too. Right
now it is not an immediate problem because we don't have any
ppc32(except these few old ppc32). Howver, there is working in progress
to support kexec/kdump for freescale 85xx(it is 32bit ppc). We may need
to address the problem in kexec-tools.

Thanks,
Ming

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: should kernel image destination address be picked up by kernel itself?

[Ming Lei]

Eric,

>>"Ming Lei" <mlei@Brocade.COM> writes:
>> As I understand the code, current destination address is picked up by
>> either the user(elf image) or kexec-tools. It is not automatic, can
we
>> let linux kernel choose the address instead? It is automatic and no
way
>> to wipe out something important.

>I don't follow.  The basic model of kexec is:
>2)- All of the policy decisions are made in user space (such as where
to
>  execute from)

>3)- standalone executables are loaded into an address space where
>  physical address and virtual address are the same.

>4)- Sophisticated page swapping happens in the kernel where
>  sys_kexec_load was called so that any valid address on the machine
>  is available to the standalone executable.

>What problem do you see in that model?
>Why is it a problem for you?

>Eric

I generally agree on 2). However, to choose where to copy the kimage
segments, should the kernel be the one to make this decision so to avoid
export memory map to user space, since the kernel knows where are all
the free memory. This doesn't complicate the kernel code and meanwhile
simplify the user space code and reduce the requirement for different
platforms(so other platforms doesn't need to export kernel memory map).

I think 3) and 4) is more the requirements from x86. On ppc32 I don't
see the need for it. So 3) and 4) should be in platform specifics.

Ming 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: should kernel image destination address be picked up by kernel itself?

[Eric W. Biederman]

"Ming Lei" <mlei@Brocade.COM> writes:

> Eric,
>
>>>"Ming Lei" <mlei@Brocade.COM> writes:
>>> As I understand the code, current destination address is picked up by
>>> either the user(elf image) or kexec-tools. It is not automatic, can
> we
>>> let linux kernel choose the address instead? It is automatic and no
> way
>>> to wipe out something important.
>
>>I don't follow.  The basic model of kexec is:
>>2)- All of the policy decisions are made in user space (such as where
> to
>>  execute from)
>
>>3)- standalone executables are loaded into an address space where
>>  physical address and virtual address are the same.
>
>>4)- Sophisticated page swapping happens in the kernel where
>>  sys_kexec_load was called so that any valid address on the machine
>>  is available to the standalone executable.
>
>>What problem do you see in that model?
>>Why is it a problem for you?
>
>>Eric
>
> I generally agree on 2). However, to choose where to copy the kimage
> segments, should the kernel be the one to make this decision so to avoid
> export memory map to user space, since the kernel knows where are all
> the free memory. This doesn't complicate the kernel code and meanwhile
> simplify the user space code and reduce the requirement for different
> platforms(so other platforms doesn't need to export kernel memory map).

Nothing needs to export the kernel memory map.  What is exported is
the kernels knowledge of where physical memory is.  Where the running
kernel is irrelevant.

I am fairly certain openfirmware provides that interface today.
And even outside of the context of kexec we need that information to
pass to the newly loaded kernel so it knows what memory it can use.

> I think 3) and 4) is more the requirements from x86. On ppc32 I don't
> see the need for it. So 3) and 4) should be in platform specifics.

3 is the design and if ppc32 doesn't do that it is broken.

4 also is a general requirement.  It is rare an architecture will have
a 1M+ range of physically contiguous pages.

Dealing with physical addresses in early boot and not having to get
sophisticated and play page table games is very desirable.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec