[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] kexec design issues



On Mon, Mar 16, 2009 at 01:54:34PM +0000, Jan Beulich wrote:
> >>> Magnus Damm <magnus.damm@xxxxxxxxx> 16.03.09 12:19 >>>
> >So the code assumes that PA_.. are even and VA_.. are odd. The defines
> >could have been copied over to make more readable code, yes, or we
> >could have shared header files somehow. In the end the hypervisor
> >assumes the interface remains unchanged. The addresses are modified so
> >the assembly snipped can run from hypervisor address space.
> >
> >What is the real problem? Just that the interface has changed?
> 
> The issue is that the Linux side changed without having any way to
> recognize resulting problems apart from running into them. If a lower
> software layer gets designed based on implementation details of a higher
> layer, there should at least be build time checks that make sure the upper
> layer doesn't change in incompatible ways (and yes, a few checks are
> in that code, but their coverage is rather limited).
> 
> But I view the issue as broader: Any other OS wanting to make use of
> the kexec hypercall interface would be required to match the Linux
> implementation in  various respects. This is what I consider a design flaw,
> which makes me think that the current kexec sub-hypercalls should be
> urgently deprecated in favor of a clean interface.

Skipping to the chase, what do you envisage such an interface looking like?

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.