--On Monday, August 08, 2005 22:37:57 +0200 Andi Kleen <ak@xxxxxxx> wrote:
> On Mon, Aug 08, 2005 at 09:03:21PM +0100, Ian Pratt wrote:
>>
>> Folks, there's been some disucssion about the VMI interface proposal
>> between myself and Linus/Andrew. I've appeneded my latest reply.
>>
>> As regards the VMI proposal itself, I don't think I can forward it, so
>> if you don't have it you'd better ask Pratap Subrahmanyam
>> [pratap@xxxxxxxxxx] for it directly.
>
> FWIW i agree with most of your points.
>
>> [*]Having a single kernel image that works native and on a hypervisor is
>> quite convenient from a user POV. We've looked into addressing this
>> problem in a different way, by building multiple kernels and then using
>> a tool that does a function-by-function 'union' operation, merging the
>> duplicates and creating a re-write table that can be used to patch the
>> kernel from native to Xen. This approach has no run time overhead, and
>> is entirely 'mechanical' rather than having to having to do it as source
>> level that can be both tricky and messy.
>
> That sounds incredibly ugly. In particular it will make building
> kernels very messy, which is a bad thing.
Ian, did you look at the generic subarch, and see how that works? Not
sure if that's what you mean or not - may arrive at the same end, but
by an easier path?
If we use function pointers, and do so at a high enough abstraction
level, I don't think the perf impact is too bad. there's always the
possiblity to rewrite some of the code on the fly like the cpu code,
just to shortcut those branches (though with branch prediction on
modern chips, it may not do much). I *think* that's equivalent to
what you're saying above ... but takes away the scary bit about
"multiple kernels" ;-)
M.
_______________________________________________
Xen-merge mailing list
Xen-merge@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-merge
|
Home