| |
|
 |
|
 |
|
|
|
| |
|
|
xen-merge
RE: [Xen-merge] FW: vmware's virtual machine interface
> >> [*]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.
[I wish I hadn't mentioned this at all now -- it certainly wasn't
central to the argument I ws making]
As it is, it wouldn't actually make the build process too ugly. You can
build any number of vmlinux files with whatever config options you like,
and then just pass them to a magic program that smashes them together by
doing function-by-function comparisons. For example, you could do this
with a PAE and non-PAE kernel...
> 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?
The approach is my footnote is hypothetical, but with the experimenting
I did last year I came to the conclusion it would work.
Sure, it could be done at source level with a high-enough abstraction,
but its not immediately obvious to me that such boot-time nastiness
couldn't just be hidden in a tool operating on the binary.
Just looking at what changes would be required to auto-switch between
PAE and non PAE makes me think that the idea shouldn't be immediately
discounted.
Best,
Ian
> 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
>
_______________________________________________
Xen-merge mailing list
Xen-merge@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-merge
|
|
|
| |
|
Home