xen-devel
[Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravi
To: |
Rusty Russell <rusty@xxxxxxxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable |
From: |
ebiederm@xxxxxxxxxxxx (Eric W. Biederman) |
Date: |
Mon, 19 Mar 2007 12:25:12 -0600 |
Cc: |
zach@xxxxxxxxxx, jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, chrisw@xxxxxxxxxxxx, Andi Kleen <ak@xxxxxx>, anthony@xxxxxxxxxxxxx, mingo@xxxxxxx, torvalds@xxxxxxxxxxxxxxxxxxxx, David Miller <davem@xxxxxxxxxxxxx> |
Delivery-date: |
Tue, 20 Mar 2007 02:26:36 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<1174272469.11680.23.camel@xxxxxxxxxxxxxxxxxxxxx> (Rusty Russell's message of "Mon, 19 Mar 2007 13:47:49 +1100") |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<20070316.023331.59468179.davem@xxxxxxxxxxxxx> <45FB005D.9060809@xxxxxxxx> <1174127638.8897.75.camel@xxxxxxxxxxxxxxxxxxxxx> <20070318.003309.71088169.davem@xxxxxxxxxxxxx> <20070318120814.GA45869@xxxxxx> <1174272469.11680.23.camel@xxxxxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Rusty Russell <rusty@xxxxxxxxxxxxxxx> writes:
> On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
>> > The idea is _NOT_ that you go look for references to the paravirt_ops
>> > members structure, that would be stupid and you wouldn't be able to
>> > use the most efficient addressing mode on a given cpu, you'd be
>> > patching up indirect calls and crap like that. Just say no...
>>
>> That wouldn't handle inlines though. At least some of the current
>> paravirtops like cli/sti are critical enough to require inlining.
>
> Well, we'd patch the inline over the call if we have room.
>
> Magic patching would be neat, but the downsides are that (1) we can't
> expand the patching room and (2) there's no way of attaching clobber
> info to the call site (doing register liveness analysis is not
> appealing).
True. You can use all of the call clobbered registers.
> Now, this may not be fatal. 5 bytes is enough for all the native ops to
> be patched inline. For lguest this covers popf and pushf, but not cli
> and sti (10 bytes): they'd have to be calls.
>
> As for clobber info, it turns out that almost all of the calls can
> clobber %eax, which is probably enough. We just need to mark the
> handful of asm ones where this isn't true.
I guess if the code is larger than a function call I'm failing to see
the disadvantage in making it a direct function call. Any modern
processor ought to be able to predict it perfectly, and processors
like the P4 may even optimize the call out of their L1 instruction
cache.
If what David is suggesting works, making all of these direct calls
looks easy and very maintainable. At which point patching
instructions inline is quite possibly overkill.
Is it truly critical to inline any of these instructions?
Eric
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, (continued)
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Linus Torvalds
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Andrew Morton
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Chuck Ebbert
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Zachary Amsden
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Jeremy Fitzhardinge
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Rusty Russell
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable,
Eric W. Biederman <=
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Chris Wright
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Jeremy Fitzhardinge
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Andi Kleen
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, David Miller
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Jeremy Fitzhardinge
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Linus Torvalds
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Jeremy Fitzhardinge
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Rusty Russell
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Zachary Amsden
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Rusty Russell
|
|
|