Re: [Xen-devel] [PATCH 1/3] kexec: extend hypercall with improved load/unload ops

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Thu, Jan 17, 2013 at 05:53:17PM +0000, David Vrabel wrote:
> On 17/01/13 15:17, Daniel Kiper wrote:
> > On Thu, Jan 17, 2013 at 02:50:26PM +0000, David Vrabel wrote:
> >> On 17/01/13 12:28, Daniel Kiper wrote:
> >>> On Wed, Jan 16, 2013 at 04:29:04PM +0000, David Vrabel wrote:
> [..]
> >>>> +    if ( image->class == KEXEC_CLASS_32 )
> >>>> +        compat_machine_kexec(image->entry_maddr);
> >>>
> >>> Why do you need that?
> >>
> >> image->class controls whether the processor is in 32-bit or 64-bit mode
> >> when calling the image.  The current implementation only allows images
> >> to be executed with the same class as dom0.
> >>
> >> It's called class because that's the term ELF uses in the ELF header.
> >
> > As I correctly understand this sets processor mode before new kernel 
> > exection.
> > If yes then it is not needed. Purgatory code (from kexec-tools) does all
> > needed things. Please check.
>
> On x86 I think it would probably be fine to specify entry is always in

Which entry? Kernel entry point? I think it is always the same.

> 64-bit mode but for ARM and future architectures it is less clear and it
> becomes more difficult to have a well-defined ABI.
>
> In fact, we probably want a more generic architecture field. e.g,
>
> #define XEN_KEXEC_ARCH_X86_32 0
> #define XEN_KEXEC_ARCH_X86_64 1
> #define XEN_KEXEC_ARCH_ARMv7  2
> #define XEN_KEXEC_ARCH_ARMv8  3

If we need them then please look into linux/include/uapi/linux/kexec.h.
In Linux Kernel case they are passed via flags.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel