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

From: Chris Wright
Date: Wed Mar 22 2006 - 17:48:35 EST


* 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/