All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	eauger@redhat.com, fweimer@redhat.com, jeremy.linton@arm.com,
	oliver.upton@linux.dev, pbonzini@redhat.com,
	stable@vger.kernel.org, tabba@google.com, wilco.dijkstra@arm.com,
	will@kernel.org
Subject: Re: [PATCH 7/8] KVM: arm64: Mark some header functions as inline
Date: Thu, 06 Feb 2025 12:28:42 +0000	[thread overview]
Message-ID: <86r04btfyd.wl-maz@kernel.org> (raw)
In-Reply-To: <Z6SVGbr7cvrVnNMz@J2N7QTR9R3>

On Thu, 06 Feb 2025 10:55:21 +0000,
Mark Rutland <mark.rutland@arm.com> wrote:
> 
> On Thu, Feb 06, 2025 at 10:42:29AM +0000, Marc Zyngier wrote:
> > On Thu, 06 Feb 2025 10:03:46 +0000,
> > Mark Rutland <mark.rutland@arm.com> wrote:
> > > That said, I'm going to go with the below, adding 'inline' to
> > > kvm_hyp_handle_memory_fault() and using CPP defines to alias the
> > > function names:
> > > 
> > > | static inline bool kvm_hyp_handle_memory_fault(struct kvm_vcpu *vcpu,
> > > |                                                u64 *exit_code)
> > > | {
> > > |         if (!__populate_fault_info(vcpu))
> > > |                 return true;
> > > | 
> > > |         return false;
> > > | }
> > > | #define kvm_hyp_handle_iabt_low         kvm_hyp_handle_memory_fault
> > > | #define kvm_hyp_handle_watchpt_low      kvm_hyp_handle_memory_fault
> > > 
> > > I think that's clearer, and it's more alisnged with how we usually alias
> > > function names in headers. Other than these two cases, __alias() is only
> > > used in C files to create a sesparate exprted symbol, and it's odd to
> > > use it in a header anyhow.
> > > 
> > > Marc, please should if you'd prefer otherwise.
> > 
> > Nah, that's fine by me.
> > 
> > My only issue was with marking functions as inline, and yet storing
> > pointers to these functions. But it looks like the compiler (GCC 12.2
> > in my case) is doing a good job noticing the weird pattern, and
> > generating only one function, even if we store multiple pointers.
> 
> That's fair -- I'm fairly certain that we do this elsewhere too, but I
> can switch to __maybe_unused if we're worried that might bite us in
> future?

Sure, that'd be equally fine.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


  reply	other threads:[~2025-02-06 12:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-04 15:20 [PATCH 0/8] KVM: arm64: FPSIMD/SVE/SME fixes Mark Rutland
2025-02-04 15:20 ` [PATCH 1/8] KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state Mark Rutland
2025-02-04 15:56   ` Mark Brown
2025-02-05 12:31   ` Eric Auger
2025-02-04 15:20 ` [PATCH 2/8] KVM: arm64: Remove host FPSIMD saving for non-protected KVM Mark Rutland
2025-02-04 16:55   ` Mark Brown
2025-02-04 15:20 ` [PATCH 3/8] KVM: arm64: Remove VHE host restore of CPACR_EL1.ZEN Mark Rutland
2025-02-04 17:20   ` Mark Brown
2025-02-04 15:20 ` [PATCH 4/8] KVM: arm64: Remove VHE host restore of CPACR_EL1.SMEN Mark Rutland
2025-02-04 17:23   ` Mark Brown
2025-02-04 15:20 ` [PATCH 5/8] KVM: arm64: Refactor CPTR trap deactivation Mark Rutland
2025-02-04 15:20 ` [PATCH 6/8] KVM: arm64: Refactor exit handlers Mark Rutland
2025-02-04 15:20 ` [PATCH 7/8] KVM: arm64: Mark some header functions as inline Mark Rutland
2025-02-04 18:17   ` Mark Brown
2025-02-05 21:50   ` Mark Brown
2025-02-06 10:01     ` Mark Rutland
2025-02-06 10:03     ` Mark Rutland
2025-02-06 10:42       ` Marc Zyngier
2025-02-06 10:55         ` Mark Rutland
2025-02-06 12:28           ` Marc Zyngier [this message]
2025-02-06 13:32             ` Mark Rutland
2025-02-04 15:21 ` [PATCH 8/8] KVM: arm64: Eagerly switch ZCR_EL{1,2} Mark Rutland
2025-02-04 18:00   ` Marc Zyngier
2025-02-06 10:28     ` Mark Rutland

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=86r04btfyd.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=eauger@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tabba@google.com \
    --cc=wilco.dijkstra@arm.com \
    --cc=will@kernel.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.