From: Marc Zyngier <maz@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>
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:23:52 +0100 [thread overview]
Message-ID: <87k0lt6vnr.wl-maz@kernel.org> (raw)
In-Reply-To: <20210714095601.184854-4-alexandru.elisei@arm.com>
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).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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: Marc Zyngier <maz@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>
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:23:52 +0100 [thread overview]
Message-ID: <87k0lt6vnr.wl-maz@kernel.org> (raw)
In-Reply-To: <20210714095601.184854-4-alexandru.elisei@arm.com>
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).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-07-14 10:24 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 [this message]
2021-07-14 10:23 ` Marc Zyngier
2021-07-14 10:40 ` Alexandru Elisei
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=87k0lt6vnr.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=alexandru.elisei@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.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.