RE: [Xen-merge] FW: vmware's virtual machine interface

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

 > >> [*]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