All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: Andrew Cooper <amc96@srcf.net>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Jan Beulich" <JBeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Bertrand Marquis" <bertrand.marquis@arm.com>
Subject: Re: [PATCH 1/5] xen/domain: Remove function pointers from domain pause helpers
Date: Thu, 18 Nov 2021 09:28:24 +0000	[thread overview]
Message-ID: <f46d7a85-b323-1219-8409-b435720846a6@xen.org> (raw)
In-Reply-To: <23b5c4ae-d4da-3d01-42f3-17f1504a0a6a@srcf.net>

Hi Andrew,

On 18/11/2021 01:47, Andrew Cooper wrote:
> On 12/11/2021 09:36, Julien Grall wrote:
>> On 11/11/2021 17:57, Andrew Cooper wrote:
>>> Retpolines are expensive, and all these do are select between the 
>>> sync and
>>> nosync helpers.  Pass a boolean instead, and use direct calls 
>>> everywhere.
>>
>> To be honest, I much prefer to read the old code. I am totally not 
>> against the change but I can see how I would be ready to introduce new 
>> function pointers use in the future.
> 
> Really?  The only reason there are function points to begin with was 
> because of a far more naive (and far pre-spectre) me fixing a reference 
> counting mess in 2014 by consolidating the logic.  My mistake was not 
> spotting that the function pointers weren't actually necessary in the 
> first place.
> 
>> So I think we need some guidelines on when to use function pointers in 
>> Xen.
> 
> It's easy.  If you are in any way unsure, they're probably the wrong 
> answer.  (Ok - I'm being a little facetious)
> 
> There are concrete security improvements from not using function 
> pointers, demonstrated by fact that JOP/COP attacks are so pervasive 
> that all major hardware and software vendors are working on techniques 
> (both hardware and software) to prevent forward-edge control flow 
> integrity violations.  (The mandate from the NSA to make this happen 
> certainly helped spur things on, too.)
> 
> There are also concrete performance improvements too.  All competitive 
> processors in the market today can cope with direct branches more 
> efficiently than indirect branches, and a key principle behind 
> profile-guided-optimsiation is to rearrange your `ptr()` function 
> pointer call into `if ( ptr == a ) a(); else if ( ptr == b ) b(); else 
> ptr()` based on the frequency of destinations, because this really does 
> make orders of magnitude improvements in some cases.
> 
> We have some shockingly inappropriate uses of function pointers in Xen 
> right now (patches 4 and 5 in particular, and "x86/hvm: Remove callback 
> from paging->flush_tlb() hook" posted today).  While this specific 
> example doesn't fall into shockingly inappropriate in my books, it is 
> firmly in the "not appropriate" category.

Thanks for the full explanation. What I am looking for is an update of 
CODING_STYLE to make clear the function pointers should be avoided in 
Xen and when we would accept them.

>>> This actually compiles smaller than before:
>>
>> ... the code doesn't really compile smaller on Arm:
>>
>> 42sh>  ../scripts/bloat-o-meter xen-syms-old xen-syms
>>
>> add/remove: 4/2 grow/shrink: 0/6 up/down: 272/-252 (20)
>> Function old     new   delta
>> _domain_pause                                  -     136    +136
>> _domain_pause_by_systemcontroller              -     120    +120
>> domain_pause_by_systemcontroller_nosync        -       8      +8
>> domain_pause_by_systemcontroller               -       8      +8
>> domain_resume                                136     132      -4
>> domain_pause_nosync                           12       8      -4
>> domain_pause                                  12       8      -4
>> domain_pause_except_self                     188     180      -8
>> do_domctl                                   5480    5472      -8
>> domain_kill                                  372     356     -16
>> do_domain_pause                               88       -     -88
>> __domain_pause_by_systemcontroller           120       -    -120
>> Total: Before=966919, After=966939, chg +0.00%
> 
> 
> ARM, like x86, compiles for speed, not size.  "it got a bit larger" is 
> generally not as interesting as "it got smaller, despite everything the 
> compiler would normally do in the opposite direction".

My point is you have a generic section "this compiles smaller" section 
in your commit message when in fact this was only tested with one x86 
compiler version.

So at the minimum you should specify the version/architecture because 
otherwise this sounds like you claim smaller Xen for everyone.

But to be honest, I don't really see the value to mention them as this 
is depending on your compiler (e.g. it may be bigger or smaller) and as 
you wrote it yourself "you're saying that for an removed 5 instructions".

Cheers,

-- 
Julien Grall


  reply	other threads:[~2021-11-18  9:28 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 17:57 [PATCH 0/5] xen: various function pointer cleanups Andrew Cooper
2021-11-11 17:57 ` [PATCH 1/5] xen/domain: Remove function pointers from domain pause helpers Andrew Cooper
2021-11-12  9:36   ` Julien Grall
2021-11-18  1:47     ` Andrew Cooper
2021-11-18  9:28       ` Julien Grall [this message]
2021-11-12  9:57   ` Jan Beulich
2021-11-17 23:31     ` Andrew Cooper
2021-11-15 10:13   ` Bertrand Marquis
2021-11-15 10:20     ` Jan Beulich
2021-11-15 10:23       ` Bertrand Marquis
2021-11-15 10:55         ` Jan Beulich
2021-11-15 11:23           ` Bertrand Marquis
2021-11-15 14:11             ` Julien Grall
2021-11-15 14:45               ` Bertrand Marquis
2021-11-16  0:41           ` Stefano Stabellini
2021-11-16  7:15             ` Jan Beulich
2021-11-11 17:57 ` [PATCH 2/5] xen/domain: Improve pirq handling Andrew Cooper
2021-11-12 10:16   ` Jan Beulich
2021-11-11 17:57 ` [PATCH 3/5] xen/sort: Switch to an extern inline implementation Andrew Cooper
2021-11-11 18:15   ` Julien Grall
2021-11-16  0:36     ` Stefano Stabellini
2021-11-16  0:41       ` Andrew Cooper
2021-12-17 15:56         ` Andrew Cooper
2021-12-17 16:15           ` Julien Grall
2021-11-12  9:39   ` Julien Grall
2021-11-12 10:25   ` Jan Beulich
2021-11-11 17:57 ` [PATCH 4/5] xen/wait: Remove indirect jump Andrew Cooper
2021-11-12 10:35   ` Jan Beulich
2021-11-11 17:57 ` [PATCH 5/5] x86/ioapic: Drop function pointers from __ioapic_{read,write}_entry() Andrew Cooper
2021-11-12 10:43   ` Jan Beulich
2021-11-18  0:32     ` Andrew Cooper
2021-11-18  9:06       ` Jan Beulich
2021-11-18  9:07         ` Jan Beulich
2021-11-18 17:33           ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f46d7a85-b323-1219-8409-b435720846a6@xen.org \
    --to=julien@xen.org \
    --cc=JBeulich@suse.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=amc96@srcf.net \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.