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

[Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching



* Zachary Amsden (zach@xxxxxxxxxx) wrote:
> Chris Wright wrote:
> >Strongly agreed.  The strict ABI requirements put forth here are not
> >in-line with Linux, IMO.  I think source compatibility is the limit of
> >reasonable, and any ROM code be in-tree if something like this were to
> >be viable upstream.
> 
> Strongly disagree.  Without an ABI, you don't have binary 
> compatibility.  Without binary compatibility, you have no way to inline 
> any hypervisor code into the kernel.  And this is key for performance.  
> The ROM code is being phased out.

With source compatibility you get the ABI at compile time.  This is how
Linux handles internal interfaces.  This is about an internal interface
between kernel and a platform layer.  The raw hypervisor interface is
hidden (translations done in the platform layer), and the hypervisor
needs to provide stable ABI.

> Is it the strictness of the ABI that is the problem?  I don't like 
> constraining the native register values any much either, but it was the 
> expedient thing to do.  The ABI can be relaxed quite a bit, but it has 
> to be there.

It's the very notion of creating such a large internal binary compatible
interface.

> The idea of in-tree ROM code doesn't make sense.  The entire point of 
> this layer of code is that it is modular, and specific to the 
> hypervisor, not the kernel.  Once you lift the shroud and combine the 
> two layers, you have lost all of the benefit that it was supposed to 
> provide.

You could compile all platform layers you want to support with the kernel.

thanks,
-chris

_______________________________________________
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®.