[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information



On 17/01/17 19:00, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2017 at 01:42:54PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Jan 17, 2017 at 06:16:36PM +0000, Andrew Cooper wrote:
>>> On 17/01/17 18:05, Konrad Rzeszutek Wilk wrote:
>>>> On Mon, Jan 16, 2017 at 01:04:09PM +0000, Andrew Cooper wrote:
>>>>> The chageset/version/compile information is currently exported as a set of
>>>>> function calls into a separate translation unit, which is inefficient for 
>>>>> all
>>>>> callers.
>>>>>
>>>>> Replace the function calls with externs pointing appropriately into 
>>>>> .rodata,
>>>>> which allows all users to generate code referencing the data directly.
>>>>>
>>>>> No functional change, but causes smaller and more efficient compiled code.
>>>>>
>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> Ah crud. That breaks the livepatch test-cases (they patch the 
>>>> xen_extra_version
>>>> function).
>>> Lucky I haven't pushed it then, (although the livepatch build seems to
>>> still work fine for me, despite this change.)
>> make tests should fail.
> (which is not by built by default as requested by Jan - but the
> OSSTest test cases I am working would do this).
>>>> Are there some other code that can be modified that is reported
>>>> by 'xl info' on which the test-cases can run (and reported easily?).
>>> Patch do_version() itself to return the same difference of information?
>> Ugh. That is going to make the building of test-cases quite complex.
>>
>> I guess it can just do it and .. return only one value :-)
> As in something like this (not compile tested):
>
>
> diff --git a/xen/arch/x86/test/xen_hello_world_func.c 
> b/xen/arch/x86/test/xen_hello_world_func.c
> index 2e4af9c..3572600 100644
> --- a/xen/arch/x86/test/xen_hello_world_func.c
> +++ b/xen/arch/x86/test/xen_hello_world_func.c
> @@ -10,7 +10,7 @@
>  static unsigned long *non_canonical_addr = (unsigned long 
> *)0xdead000000000000ULL;
>  
>  /* Our replacement function for xen_extra_version. */
> -const char *xen_hello_world(void)
> +const char *xen_version_hello_world(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
> arg)
>  {
>      unsigned long tmp;
>      int rc;
> @@ -21,7 +21,19 @@ const char *xen_hello_world(void)
>      rc = __get_user(tmp, non_canonical_addr);
>      BUG_ON(rc != -EFAULT);
>  
> -    return "Hello World";
> +    if ( cmd == XENVER_extraversion )
> +    {
> +        xen_extraversion_t extraversion = "Hello World";
> +
> +        if ( copy_to_guest(arg, extraversion, ARRAY_SIZE(extraversion)) )
> +            return -EFAULT;
> +        return 0;
> +    }
> +    /*
> +     * Can't return -EPERM as certain subversions can't deal with negative
> +     * values.
> +     */
> +    return 0;
>  }
>
>
> That will make three of the test-patches work but not for the last
> one - the NOP one (which needs to patch the _whole_ function).
>
> Argh.
>
> Is this patch of yours that neccessary? Could at least some of the
> functions still exist?

Well.  This patch is manually doing what LTO would do automatically when
it has a cross-translation-unit view of things, and come to the
conclusion that in all cases, inlining cross-unit will make the calling
code shorter, and allow the functions to be elided entirely.

I take it from this that noone has tried livepatching an LTO build of Xen.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.