All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Henry.Wang@arm.com" <Henry.Wang@arm.com>, Wei Liu <wl@xen.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH for-4.17 v4 2/2] amd: remove VIRT_SC_MSR_HVM synthetic feature
Date: Wed, 16 Nov 2022 11:11:56 +0100	[thread overview]
Message-ID: <Y3S3bGaWXSmcAvAJ@Air-de-Roger> (raw)
In-Reply-To: <a43058ad-98eb-f558-3b21-65054e163c22@suse.com>

On Wed, Nov 16, 2022 at 08:41:06AM +0100, Jan Beulich wrote:
> On 16.11.2022 00:54, Andrew Cooper wrote:
> > On 15/11/2022 16:44, Jan Beulich wrote:
> >> I think we need to settle on at least halfway firm rules on when to use
> >> synthetic feature bits and when to use plain global booleans. Without
> >> that the tastes of the three of us are going to collide again every once
> >> in a while.
> > 
> > Its very easy.  All other things being equal, synthetic features are the
> > most efficient option.
> 
> See Roger's better wording of "why use a more complicated construct when
> a simple one will do". Yes, generated code may be better in certain cases,
> but no, we don't always judge by that aspect alone. Source simplicity is
> an important criteria, which at other times I recall you also weighing
> higher than the performance of resulting code (especially when dealing
> with performance aspects when they don't really matter at most/all use
> sites of whichever construct).

I think it would be easier if we can discuss this in one of our x86
related meetings.  It's still unclear to me why a synthetic feature
would be preferred rather than a global variable in most cases (like
the one here, even if the variable didn't end up having the __init
attribute).

Thanks, Roger.


  reply	other threads:[~2022-11-16 10:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-15 13:26 [PATCH for-4.17 v4 0/2] amd/virt_ssbd: refactoring and fixes Roger Pau Monne
2022-11-15 13:26 ` [PATCH for-4.17 v4 1/2] amd/virt_ssbd: set SSBD at vCPU context switch Roger Pau Monne
2022-11-15 13:26 ` [PATCH for-4.17 v4 2/2] amd: remove VIRT_SC_MSR_HVM synthetic feature Roger Pau Monne
2022-11-15 16:21   ` Andrew Cooper
2022-11-15 16:44     ` Jan Beulich
2022-11-15 23:54       ` Andrew Cooper
2022-11-16  7:41         ` Jan Beulich
2022-11-16 10:11           ` Roger Pau Monné [this message]
2022-11-15 16:50     ` Roger Pau Monné
2022-11-16  0:27 ` [PATCH for-4.17 v4 0/2] amd/virt_ssbd: refactoring and fixes Andrew Cooper
2022-11-16  9:53   ` Roger Pau Monné

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=Y3S3bGaWXSmcAvAJ@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=Henry.Wang@arm.com \
    --cc=jbeulich@suse.com \
    --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.