[lkml]   [2007]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
On Fri, 2007-03-16 at 10:24 +0100, Ingo Molnar wrote:
> * Jeremy Fitzhardinge <> wrote:
> > Wrap a set of interesting paravirt_ops calls in a wrapper which makes
> > the callsites available for patching. Unfortunately this is pretty
> > ugly because there's no way to get gcc to generate a function call,
> > but also wrap just the callsite itself with the necessary labels.
> >
> > This patch supports functions with 0-4 arguments, and either void or
> > returning a value. 64-bit arguments must be split into a pair of
> > 32-bit arguments (lower word first). Small structures are returned in
> > registers.
> ugh. This is beyond ugly! Why dont we just compile two images, one for
> Xen and one for native, do two passes to get those two images and
> 'merge' them into a single vmlinuz (so that we still have a 'single'
> kernel unit to deal with on the distro side). This way we avoid all this
> crazy, limited, fragile patchery business...

But with lguest, VMI and kvm I don't think that's a good idea.

For background: the current patching code is ugly too, but it only deals
with the 6 most common functions, so it's contained. This gets us
pretty close to !CONFIG_PARAVIRT performance. (But slowdown is still

We get worse with Xen wanting to alter mkpte et al. By the time we
patch another 6 functions (each one slightly different), we get pretty
close to general coverage anyway, so it's clearer to do them all.

I think the question is, can we do it better than this? My previous
attempts (which lead to the current code) ranged from ugly to very ugly


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-03-18 01:49    [W:0.173 / U:5.496 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site