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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-01-17 at 17:53 +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
> 64-bit mode but for ARM and future architectures it is less clear and it
> becomes more difficult to have a well-defined ABI.

Just a random thought but rather than an entry point would it make sense
to pass in a complete struct vcpu_guest_context?  Not all of the members
would be relevant to this use case but a bunch of them other than PC
might be?

Ian.


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