All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/5] KVM: arm64: Rename __vcpu_sys_reg -> vcpu_sys_reg
Date: Wed, 14 Jul 2021 11:40:35 +0100	[thread overview]
Message-ID: <1ec785be-799f-12ea-e9f7-5e4d06b02145@arm.com> (raw)
In-Reply-To: <87k0lt6vnr.wl-maz@kernel.org>

Hi Marc,

On 7/14/21 11:23 AM, Marc Zyngier wrote:
> Hi Alex,
>
> On Wed, 14 Jul 2021 10:55:59 +0100,
> Alexandru Elisei <alexandru.elisei@arm.com> wrote:
>> There are two macros to access a specific system register from a known
>> kvm_cpu_context: __ctxt_sys_reg(), which returns a pointer to the register,
>> and ctxt_sys_reg(), which deferences the pointer returned by
>> __ctxt_sys_reg().
>>
>> __vcpu_sys_reg() serves a similar purpose, with the difference being that
>> it takes a struct kvm_vcpu as a parameter. __vcpu_sys_reg(), although it
>> looks like __ctxt_sys_reg(), it dereferences the pointer to the register,
>> like ctxt_sys_reg() does, and indeed it is defined as an abstraction over
>> ctxt_sys_reg().
>>
>> Let's remove this naming inconsistency by renaming __vcpu_sys_reg() to
>> vcpu_sys_reg(), to make it clear it behaves like ctxt_sys_reg(), and not
>> like __ctxt_sys_reg().
> I can't say I'm keen on this change.
>
> The leading underscores really are there to outline that *this is
> dangerous*, as you really need to know which context you are in.
> Dropping the leading '__' may give the false impression that this is
> safe, and not actually a primitive that requires careful thinking
> before use.
>
> ctxt_sys_reg() is, on the other hand, clearly something that acts
> solely on memory because it takes a context structure, and not a
> vcpu. At least that's what the 'ctxt' prefix is supposed to convey
> (not very successfully, apparently).

Oh, so that's the real reason for the leading underscores, I assumed that the
comment was warning enough. Since the 3 macros were right next to each other, and
__vcpu_sys_reg() is a wrapper over ctxt_sys_reg(), I thought they're there to
differentiate between returning a reference and returning a value. I'll drop this
patch and the one after it.

Thanks,

Alex

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, james.morse@arm.com,
	suzuki.poulose@arm.com
Subject: Re: [PATCH 3/5] KVM: arm64: Rename __vcpu_sys_reg -> vcpu_sys_reg
Date: Wed, 14 Jul 2021 11:40:35 +0100	[thread overview]
Message-ID: <1ec785be-799f-12ea-e9f7-5e4d06b02145@arm.com> (raw)
In-Reply-To: <87k0lt6vnr.wl-maz@kernel.org>

Hi Marc,

On 7/14/21 11:23 AM, Marc Zyngier wrote:
> Hi Alex,
>
> On Wed, 14 Jul 2021 10:55:59 +0100,
> Alexandru Elisei <alexandru.elisei@arm.com> wrote:
>> There are two macros to access a specific system register from a known
>> kvm_cpu_context: __ctxt_sys_reg(), which returns a pointer to the register,
>> and ctxt_sys_reg(), which deferences the pointer returned by
>> __ctxt_sys_reg().
>>
>> __vcpu_sys_reg() serves a similar purpose, with the difference being that
>> it takes a struct kvm_vcpu as a parameter. __vcpu_sys_reg(), although it
>> looks like __ctxt_sys_reg(), it dereferences the pointer to the register,
>> like ctxt_sys_reg() does, and indeed it is defined as an abstraction over
>> ctxt_sys_reg().
>>
>> Let's remove this naming inconsistency by renaming __vcpu_sys_reg() to
>> vcpu_sys_reg(), to make it clear it behaves like ctxt_sys_reg(), and not
>> like __ctxt_sys_reg().
> I can't say I'm keen on this change.
>
> The leading underscores really are there to outline that *this is
> dangerous*, as you really need to know which context you are in.
> Dropping the leading '__' may give the false impression that this is
> safe, and not actually a primitive that requires careful thinking
> before use.
>
> ctxt_sys_reg() is, on the other hand, clearly something that acts
> solely on memory because it takes a context structure, and not a
> vcpu. At least that's what the 'ctxt' prefix is supposed to convey
> (not very successfully, apparently).

Oh, so that's the real reason for the leading underscores, I assumed that the
comment was warning enough. Since the 3 macros were right next to each other, and
__vcpu_sys_reg() is a wrapper over ctxt_sys_reg(), I thought they're there to
differentiate between returning a reference and returning a value. I'll drop this
patch and the one after it.

Thanks,

Alex


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-14 10:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14  9:55 [PATCH 0/5] KVM: arm64: Cleanups and one optimization Alexandru Elisei
2021-07-14  9:55 ` Alexandru Elisei
2021-07-14  9:55 ` [PATCH 1/5] KVM: arm64: Move vcpu_has_feature() to asm/kvm_host.h Alexandru Elisei
2021-07-14  9:55   ` Alexandru Elisei
2021-07-14  9:55 ` [PATCH 2/5] KVM: arm64: Use vcpu_has_feature() to check the feature bits Alexandru Elisei
2021-07-14  9:55   ` Alexandru Elisei
2021-07-14  9:55 ` [PATCH 3/5] KVM: arm64: Rename __vcpu_sys_reg -> vcpu_sys_reg Alexandru Elisei
2021-07-14  9:55   ` Alexandru Elisei
2021-07-14 10:23   ` Marc Zyngier
2021-07-14 10:23     ` Marc Zyngier
2021-07-14 10:40     ` Alexandru Elisei [this message]
2021-07-14 10:40       ` Alexandru Elisei
2021-07-14  9:56 ` [PATCH 4/5] KVM: arm64: Add __vcpu_sys_reg() Alexandru Elisei
2021-07-14  9:56   ` Alexandru Elisei
2021-07-14  9:56 ` [PATCH 5/5] KVM: arm64: nVHE: Remove unneeded isb() when modifying PMSCR_EL1 Alexandru Elisei
2021-07-14  9:56   ` Alexandru Elisei
2021-07-14 18:20   ` Will Deacon
2021-07-14 18:20     ` Will Deacon
2021-07-15  9:31     ` Alexandru Elisei
2021-07-15  9:31       ` Alexandru Elisei

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=1ec785be-799f-12ea-e9f7-5e4d06b02145@arm.com \
    --to=alexandru.elisei@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@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.