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

Re: [PATCH v2 01/10] xen: Implement xen/alternative-call.h for use in common code


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Tue, 13 Jul 2021 09:36:58 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RyYacCnsEOtfBZL26rEsFEhjatanWjE22XhyJQZInP0=; b=ma8i2NNhEniBxk9iUme4VTaPPflWO73HH4/lnGNAGBcn8Ul7HlUXS9ZDPavNFLweNNWOGk8GYNR+9i58Vkm5trN5CRQjrkAHJ+E2qP3gK0EaNyBSbTz+rVmcNNcGNAIrZfRNKkQSwAARwUqUKFjoZDWHUhzwqYFtuoVil5P2vgeeVhv+7JTNw8UQ+DBVPbY78mJ7pxuyOzEceeTnmujOeRl3BtFPatqR9eZ4r9AO7//MJ/U9lCB6DqePXbnoqxxogwVvRym6ymt3AfJEi5xiAyegCBeeFUBnbJ9NdMD/uxqoNhc73wifggNQgF3Kk5VYWX5RmRakPPQdnMvtUoo6xA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fuWH7WFs/PPlylsdGhB91LzFOS/TKUfWL6mze9kX1lBOD3ApC/KnFByH+QEWu24IRX88AMwfmJ0HlF9aTStAorFBtnmndxOnzIF+VKUr65sCk6ufpqjQUmtRnqqM6IE9BrLyEeWfAa8i0bFJt9pSYHwVT6B5VPQgxFYfV81ozDE92AGh4DkmN1bc1hwKHWjSAsT+117rpV24dlkwHMDO0W9+funbjTk4sJiBRlq0g1vHdqgWcaiN9ZYjJOwSafV7D6YODuDQK9fgC7HmUujXhAEtkM8e6lP0ML16F4Oxwos8PU5jt/gpWl9n98T1sCOSHh9+nfHaMwiDNeNxumBYUQ==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 13 Jul 2021 08:37:32 +0000
  • Ironport-hdrordr: A9a23:F/cZ1Kthop9uACUt0OlE5L5C7skCmIMji2hC6mlwRA09TyXGra 6TdaUguiMc1gx8ZJhBo7C90KnpewK5yXcH2/huAV7EZniYhILIFvAf0WKG+Vzd8kLFh5VgPM tbAs5D4ZjLfCVHZKXBkXqF+rQbsaG6GcmT7I+0pRodLnAJGtRdBkVCe2Gm+yVNNXl77PECZe OhD6R81l+dkDgsH76G7i5vZZmzmzSHruOoXTc2QzocrCWehzKh77D3VzCewxclSjtKhZMv63 LMnQDV7riq96jT8G6c60bjq7Bt3PfxwNpKA8KBzuATNzXXkw6tIKBsQaeLsjwZqPymrHwqjN 7PiRE9ONkb0QKeQkiF5T/WnyXw2jcn7HHvjXWCh2H4nMD/TDUmT+JcmINwaHLimggdleA59J gO83OStpJRAx+Ftj/6/cL0WxZjkVfxiWY+kNQUk2dUXeIlGfxsRLQkjQdo+ao7bWXHANhNKp gpMCic3ocXTbqiVQGdgoE1q+bcB0jad3y9Mzo/Us/86UkdoJk29TpB+CSz9k1wva7VcKM0kN gsBJ4Y342mfvVmGZ6VO91xN/dfKla9DC4kY1jibWgOKsk8SjrwQtjMke4I2N0=
  • Ironport-sdr: DWBwoMmAMU7KUY1W6lkCoo5xleip9DSMbuvvxU//otzxrk9PBs12Ad2vBzJUO2ljgAkTsbp9BK Nwc80pb8ee03xSVGEQfpnfVF3TnX8rgG0Ae4O6il14Vw2CYPXKvyTn/SAOhcQr1rQ1EBqnJEey afdBQ8li5UNvoHbBK5t3U0QgFN1TG1WQJchLKGq/u5/5OgD4rJmTMhch9jj0jbAJNA/43aV7Sn sCnuFAHWR1nrDZ4FGninfJ9mPtEGTECQcnetgo25ET4qgIafPaHNl9ewGytwWoA5VOJIC5edy/ WR8=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 13/07/2021 07:28, Jan Beulich wrote:
> On 13.07.2021 01:48, Andrew Cooper wrote:
>> On 12/07/2021 21:32, Daniel P. Smith wrote:
>>> diff --git a/xen/include/xen/alternative-call.h 
>>> b/xen/include/xen/alternative-call.h
>>> new file mode 100644
>>> index 0000000000..11d1c26068
>>> --- /dev/null
>>> +++ b/xen/include/xen/alternative-call.h
>>> @@ -0,0 +1,65 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +#ifndef XEN_ALTERNATIVE_CALL
>>> +#define XEN_ALTERNATIVE_CALL
>>> +
>>> +/*
>>> + * Some subsystems in Xen may have multiple implementions, which can be
>>> + * resolved to a single implementation at boot time.  By default, this will
>>> + * result in the use of function pointers.
>>> + *
>>> + * Some architectures may have mechanisms for dynamically modifying .text.
>>> + * Using this mechnaism, function pointers can be converted to direct calls
>>> + * which are typically more efficient at runtime.
>>> + *
>>> + * For architectures to support:
>>> + *
>>> + * - Implement alternative_{,v}call() in asm/alternative.h.  Code 
>>> generation
>>> + *   requirements are to emit a function pointer call at build time, and 
>>> stash
>>> + *   enough metadata to simplify the call at boot once the implementation 
>>> has
>>> + *   been resolved.
>>> + * - Select ALTERNATIVE_CALL in Kconfig.
>>> + *
>>> + * To use:
>>> + *
>>> + * Consider the following simplified example.
>>> + *
>>> + *  1) struct foo_ops __alt_call_maybe_initdata ops;
>>> + *
>>> + *  2) struct foo_ops __alt_call_maybe_initconst foo_a_ops = { ... };
>>> + *     struct foo_ops __alt_call_maybe_initconst foo_b_ops = { ... };
>> It occurs to me after reviewing patch 2 that these want to be const
>> struct foo_ops __initconst ...,
> __initconstrel then, I suppose.
>
>> and there is no need for
>> __alt_call_maybe_initconst at all.
>>
>> The only thing wanting a conditional annotation like this is the single
>> ops object, and it needs to be initdata (or hopefully ro_after_init in
>> the future).
> ro_after_init and initdata can't be alternatives of one another; ops
> (until be gain ro_after_init) need to remain in .bss (or .data).

Once alternatives have run, the ops structure is no longer referenced by
anything at runtime, and can be reclaimed.

All the x86 examples are weird because we've either got extra data
fields which are referenced at runtime, or we've not accelerated all
function pointers.

In neither case does modifying an accelerated function pointer after the
fact do what the programmer expected, and conditionally initdata makes
this far more obvious.

~Andrew




 


Rackspace

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