public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	linux-s390@vger.kernel.org, frankja@linux.ibm.com,
	borntraeger@de.ibm.com, seiden@linux.ibm.com, nsg@linux.ibm.com,
	nrb@linux.ibm.com, david@redhat.com, agordeev@linux.ibm.com,
	svens@linux.ibm.com, gor@linux.ibm.com, schlameuss@linux.ibm.com
Subject: Re: [PATCH v2 3/5] KVM: s390: refactor some functions in priv.c
Date: Wed, 21 May 2025 17:52:12 +0200	[thread overview]
Message-ID: <20250521155212.11483Da8-hca@linux.ibm.com> (raw)
In-Reply-To: <20250520182639.80013-4-imbrenda@linux.ibm.com>

On Tue, May 20, 2025 at 08:26:37PM +0200, Claudio Imbrenda wrote:
> Refactor some functions in priv.c to make them more readable.
> 
> handle_{iske,rrbe,sske}: move duplicated checks into a single function.
> handle{pfmf,epsw}: improve readability.
> handle_lpswe{,y}: merge implementations since they are almost the same.
> 
> Use a helper function to replace open-coded bit twiddling operations.
> 
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>

...since you asked me to look into this... :)

For the sake of reviewability: I guess this really should be split
into separate patches which address one function each.

> +static inline void replace_selected_bits(u64 *w, unsigned long mask, unsigned long val)
> +{
> +	*w = (*w & ~mask) | (val & mask);
> +}
> +
> +struct skeys_ops_state {
> +	int reg1;
> +	int reg2;
> +	u64 *r1;
> +	u64 *r2;
> +	unsigned long effective;
> +	unsigned long absolute;
> +};
> +
> +static void get_regs_rre_ptr(struct kvm_vcpu *vcpu, int *reg1, int *reg2, u64 **r1, u64 **r2)
> +{
> +	kvm_s390_get_regs_rre(vcpu, reg1, reg2);
> +	*r1 = vcpu->run->s.regs.gprs + *reg1;
> +	*r2 = vcpu->run->s.regs.gprs + *reg2;
> +}

Ewww...

> +static int skeys_common_checks(struct kvm_vcpu *vcpu, struct skeys_ops_state *state)
> +{
> +	int rc;
> +
> +	if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) {
> +		rc = kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP);
> +		return rc ? rc : -EAGAIN;
> +	}

Hm.. first you introduce helper functions which use psw_bits() and now
this is open-coded again?

> +	rc = try_handle_skey(vcpu);
> +	if (rc)
> +		return rc;
> +
> +	get_regs_rre_ptr(vcpu, &state->reg1, &state->reg2, &state->r1, &state->r2);
> +
> +	state->effective = vcpu->run->s.regs.gprs[state->reg2] & PAGE_MASK;
> +	state->effective = kvm_s390_logical_to_effective(vcpu, state->effective);
> +	state->absolute = kvm_s390_real_to_abs(vcpu, state->effective);
> +
> +	return 0;
> +}

So a function which is called "*common_checks" actually may or may not
set up a state which is later used. This is anything but obvious.

>  static int handle_iske(struct kvm_vcpu *vcpu)
>  {

...

> -	vcpu->run->s.regs.gprs[reg1] &= ~0xff;
> -	vcpu->run->s.regs.gprs[reg1] |= key;
> +	replace_selected_bits(state.r1, 0xff, key);

Who is supposed to understand that this replace_selected_bits() call
actually changes vcpu->run->s.regs.gprs[reg1]? To me this obfuscates
the code and makes it much less understandable.

From my point of view this state structure and passing it back and
forth is a mistake, since it hides way too much what is actually going
on.

Anyway, just my 0.02. :)

  reply	other threads:[~2025-05-21 15:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-20 18:26 [PATCH v2 0/5] KVM: s390: some cleanup and small fixes Claudio Imbrenda
2025-05-20 18:26 ` [PATCH v2 1/5] s390: remove unneeded includes Claudio Imbrenda
2025-05-20 18:26 ` [PATCH v2 2/5] KVM: s390: remove unneeded srcu lock Claudio Imbrenda
2025-05-22 13:07   ` Christoph Schlameuss
2025-05-20 18:26 ` [PATCH v2 3/5] KVM: s390: refactor some functions in priv.c Claudio Imbrenda
2025-05-21 15:52   ` Heiko Carstens [this message]
2025-05-27  7:18   ` Nico Boehr
2025-05-27  9:14     ` Claudio Imbrenda
2025-05-20 18:26 ` [PATCH v2 4/5] KVM: s390: refactor and split some gmap helpers Claudio Imbrenda
2025-05-21 16:26   ` Heiko Carstens
2025-05-26 11:17   ` Janosch Frank
2025-05-26 11:59     ` Heiko Carstens
2025-05-26 13:21     ` Claudio Imbrenda
2025-05-20 18:26 ` [PATCH v2 5/5] KVM: s390: simplify and move pv code Claudio Imbrenda

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=20250521155212.11483Da8-hca@linux.ibm.com \
    --to=hca@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=nrb@linux.ibm.com \
    --cc=nsg@linux.ibm.com \
    --cc=schlameuss@linux.ibm.com \
    --cc=seiden@linux.ibm.com \
    --cc=svens@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox