All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Miguel Luis <miguel.luis@oracle.com>
Cc: "kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v2 0/4] KVM: arm64: vcpu sysreg accessor rework
Date: Wed, 04 Jun 2025 19:58:11 +0100	[thread overview]
Message-ID: <877c1re3lo.wl-maz@kernel.org> (raw)
In-Reply-To: <AD26CFBA-FE32-4C7D-A75B-53729B70C591@oracle.com>

On Wed, 04 Jun 2025 16:53:01 +0100,
Miguel Luis <miguel.luis@oracle.com> wrote:
> 
> 
> 
> > On 4 Jun 2025, at 15:17, Marc Zyngier <maz@kernel.org> wrote:
> > 
> > On Wed, 04 Jun 2025 11:47:57 +0100,
> > Miguel Luis <miguel.luis@oracle.com> wrote:
> >> 
> >> Hi Marc,
> >> 
> >>> On 3 Jun 2025, at 07:08, Marc Zyngier <maz@kernel.org> wrote:
> >>> 
> >>> This series tries to bring some sanity to the way the RESx masks
> >>> are applied when accessing the in-memory view of the guest's
> >>> system registers.
> >>> 
> >>> Currently, we have *one* accessor (__vcpu_sys_reg()) that can either
> >>> be used as a rvalue or lvalue while that applies the RESx masks behind
> >>> the scenes. This works fine when used as a rvalue.
> >>> 
> >>> However, when used as a lvalue, it does the wrong thing, as it only
> >>> sanitises the value we're about to overwrite. This is pointless work
> >>> and potentially hides bugs.
> >>> 
> >>> I propose that we move to a set of store-specific accessors (for
> >>> assignments and RMW) instead of the lvalue hack, ensuring that the
> >>> assigned value is the one that gets sanitised. This then allows the 
> >>> legacy accessor to be converted to rvalue-only.
> >>> 
> >>> Given the level of churn this introduces, I'd like this to land very
> >>> early in the cycle. Either before 6.16-rc2, or early in 6.17.
> >>> 
> >> 
> >> For the series:
> >> Reviewed-by: Miguel Luis <miguel.luis@oracle.com>
> > 
> > Thanks.
> > 
> >> 
> >> nit: the rmw accessor implies an implicit assignment which could be specified
> >> within its macro instead but it's fine by me.
> > 
> > I'm not sure what you mean. Looking at this macro again, the early
> > writeback to the sysreg array is pretty unfortunate, and could be
> > avoided.
> > 
> > Does the following change address your concern? If not, please clearly
> > point out what you're after.
> 
> I believe this should give a clearer idea while avoids repeating the assignment everywhere
> the accessor is used. Just replace ‘&=‘ and ‘|=‘ by ‘&’ and ‘|’.

I have the opposite view. I think the '=' sign conveys an important
meaning, and hiding it makes things less obvious. If I had lost common
sense and was writing C++ , I would have simply overloaded the various
operators, retaining the existing syntax. This macro does the hard job
of applying the RESx masks, but the operator is what is semantically
significant.

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.

  reply	other threads:[~2025-06-04 18:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-03  7:08 [PATCH v2 0/4] KVM: arm64: vcpu sysreg accessor rework Marc Zyngier
2025-06-03  7:08 ` [PATCH v2 1/4] KVM: arm64: Add assignment-specific sysreg accessor Marc Zyngier
2025-06-03 18:01   ` Miguel Luis
2025-06-04  6:52     ` Marc Zyngier
2025-06-04 10:14       ` Miguel Luis
2025-06-03  7:08 ` [PATCH v2 2/4] KVM: arm64: Add RMW specific " Marc Zyngier
2025-06-03  7:08 ` [PATCH v2 3/4] KVM: arm64: Don't use __vcpu_sys_reg() to get the address of a sysreg Marc Zyngier
2025-06-03  7:08 ` [PATCH v2 4/4] KVM: arm64: Make __vcpu_sys_reg() a pure rvalue operand Marc Zyngier
2025-06-03 21:06 ` [PATCH v2 0/4] KVM: arm64: vcpu sysreg accessor rework Oliver Upton
2025-06-04  6:54   ` Marc Zyngier
2025-06-04 10:47 ` Miguel Luis
2025-06-04 15:17   ` Marc Zyngier
2025-06-04 15:53     ` Miguel Luis
2025-06-04 18:58       ` Marc Zyngier [this message]
2025-06-05  9:40         ` Miguel Luis
2025-06-05 13:34 ` Marc Zyngier

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=877c1re3lo.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=miguel.luis@oracle.com \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=yuzenghui@huawei.com \
    /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.