Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
From: Andi Kleen <hidden>
Date: 2007-03-19 23:42:51
Also in:
lkml, virtualization, xen-devel
Possibly related (same subject, not in this thread)
- 2007-03-21 · Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable · Andrew Morton <akpm@linux-foundation.org>
- 2007-03-21 · Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable · Zachary Amsden <hidden>
- 2007-03-21 · Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable · Linus Torvalds <torvalds@linux-foundation.org>
- 2007-03-21 · Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable · Zachary Amsden <hidden>
- 2007-03-21 · Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable · Linus Torvalds <torvalds@linux-foundation.org>
Possibly not, but I'd like to be able to say with confidence that running a PARAVIRT kernel on bare hardware has no performance loss compared to running a !PARAVIRT kernel. There's the case of small instruction sequences which have been replaced with calls (such as sti/cli/push;popf/etc),
My guess is that most critical pushf/popf are in spin_lock_irqsave(). It would be possible to special case that one -- inline it -- and use out of line versions for all the others. -Andi