Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Jan 10, 2013 at 08:16:48PM -0800, Eric W. Biederman wrote:
> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> writes:
> 
> > On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
> >> I think that new kexec hypercall function should mimics kexec syscall.
> >> It means that all arguments passed to hypercall should have same types
> >> if it is possible or if it is not possible then conversion should be done
> >> in very easy way. Additionally, I think that one call of new hypercall
> >> load function should load all needed thinks in right place and
> >> return relevant status. Last but not least, new functionality should
> >
> > We are not restricted to just _one_ hypercall. And this loading
> > thing could be similar to the micrcode hypercall - which just points
> > to a virtual address along with the length - and says 'load me'.
> >
> >> be available through /dev/xen/privcmd or directly from kernel without
> >> bigger effort.
> >
> > Perhaps we should have a email thread on xen-devel where we hash out
> > some ideas. Eric, would you be OK included on this - it would make
> > sense for this mechanism to be as future-proof as possible - and I am not
> > sure what your plans for kexec are in the future?
> 
> The basic kexec interface is.
> 
> load ranges of virtual addresses physical addresses.
> jump to the physical address  with identity mapped page tables.
> 
> There are a few flags to allow for different usage scenarios like
> kexec on panic vs normal kexec.

And there is nothing fancy to be done for EFI and SecureBoot? Or is
that something that the kernel has to handle on its own (so somehow
passing some certificates to somewhere).

> 
> It is very very simple and very extensible.  All of the weird glue
> happens in userspace.
> 
> Eric

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