[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200704020911.50623.ak@suse.de>
Date: Mon, 2 Apr 2007 09:11:50 +0200
From: Andi Kleen <ak@...e.de>
To: Jeremy Fitzhardinge <jeremy@...p.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
virtualization@...ts.osdl.org, lkml <linux-kernel@...r.kernel.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Zachary Amsden <zach@...are.com>,
Anthony Liguori <anthony@...emonkey.ws>
Subject: Re: [patch 12/17] Consistently wrap paravirt ops callsites to make them patchable
On Monday 02 April 2007 07:57, 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.
Can you please add some comments to the code explaining this a little?
Best would be perhaps a overview document in Documentation too.
> +#define PVOP_CALL0(__rettype, __op) \
The __s shouldn't be needed for the macro arguments because
there is no shared name space with the caller.
> + ({ \
> + __rettype __ret; \
> + if (sizeof(__rettype) > sizeof(unsigned long)) { \
> + unsigned long long __tmp; \
> + unsigned long __ecx; \
> + asm volatile(paravirt_alt(PARAVIRT_CALL) \
Not having the volatile would probably generate better code, but it
seems much safer for now.
> + : "=A" (__tmp), "=c" (__ecx) \
> + : paravirt_type(__op), \
> + paravirt_clobber(CLBR_ANY) \
> + : "memory", "cc"); \
And the cc clobber is also not needed
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists