public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	linux-s390@vger.kernel.org,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Michael Mueller <mimu@linux.vnet.ibm.com>,
	David Hildenbrand <dahi@linux.vnet.ibm.com>
Subject: Re: [PATCH 4/4] KVM: s390: Minor refactor of base/ext facility lists
Date: Mon, 06 Nov 2023 12:38:55 +0100	[thread overview]
Message-ID: <44148ab315f28a6d77627675cbde26977418c5df.camel@linux.ibm.com> (raw)
In-Reply-To: <20231103193254.7deef2e5@p-imbrenda>

On Fri, 2023-11-03 at 19:32 +0100, Claudio Imbrenda wrote:
> On Fri,  3 Nov 2023 18:30:08 +0100
> Nina Schoetterl-Glausch <nsg@linux.ibm.com> wrote:
> 
> > Directly use the size of the arrays instead of going through the
> > indirection of kvm_s390_fac_size().
> > Don't use magic number for the number of entries in the non hypervisor
> > managed facility bit mask list.
> > Make the constraint of that number on kvm_s390_fac_base obvious.
> > Get rid of implicit double anding of stfle_fac_list.
> > 
> > Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
> > ---
> > 
> > 
> > I found it confusing before and think it's nicer this way but
> > it might be needless churn.
> 
> some things are probably overkill

I mostly wanted to get rid of kvm_s390_fac_size() since it's meaning
wasn't all that clear IMO. It's not the size of the host's facility list,
it's not the size of the guest's facility list (same as host right now,
but could be different in the future) it's the size of the arrays.

But like I said, none of it is necessary and while I'm reasonably sure
I didn't break anything, you never know :).

[...]

> >  arch/s390/kvm/kvm-s390.c | 44 +++++++++++++++++-----------------------
> >  1 file changed, 19 insertions(+), 25 deletions(-)
> > 
> > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> > index b3f17e014cab..e00ab2f38c89 100644
> > --- a/arch/s390/kvm/kvm-s390.c
> > +++ b/arch/s390/kvm/kvm-s390.c

[...]

> >  /*
> >   * Extended feature mask. Consists of the defines in FACILITIES_KVM_CPUMODEL
> >   * and defines the facilities that can be enabled via a cpu model.
> >   */
> > -static unsigned long kvm_s390_fac_ext[SIZE_INTERNAL] = { FACILITIES_KVM_CPUMODEL };
> > -
> > -static unsigned long kvm_s390_fac_size(void)
> > -{
> > -	BUILD_BUG_ON(SIZE_INTERNAL > S390_ARCH_FAC_MASK_SIZE_U64);
> > -	BUILD_BUG_ON(SIZE_INTERNAL > S390_ARCH_FAC_LIST_SIZE_U64);
> > -	BUILD_BUG_ON(SIZE_INTERNAL * sizeof(unsigned long) >
> > -		sizeof(stfle_fac_list));
> > -
> > -	return SIZE_INTERNAL;
> > -}
> > +static const unsigned long kvm_s390_fac_ext[] = { FACILITIES_KVM_CPUMODEL };
> 
> this was sized to [SIZE_INTERNAL], now it doesn't have a fixed size. is
> this intentional?

Yes, it's as big as it needs to be, that way it cannot be too small, so one
less thing to consider.

[...]
> >  /* available cpu features supported by kvm */
> >  static DECLARE_BITMAP(kvm_s390_available_cpu_feat, KVM_S390_VM_CPU_FEAT_NR_BITS);
> > @@ -3341,13 +3333,16 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> >  	kvm->arch.sie_page2->kvm = kvm;
> >  	kvm->arch.model.fac_list = kvm->arch.sie_page2->fac_list;
> >  
> > -	for (i = 0; i < kvm_s390_fac_size(); i++) {
> > +	for (i = 0; i < ARRAY_SIZE(kvm_s390_fac_base); i++) {
> >  		kvm->arch.model.fac_mask[i] = stfle_fac_list[i] &
> > -					      (kvm_s390_fac_base[i] |
> > -					       kvm_s390_fac_ext[i]);
> > +					      kvm_s390_fac_base[i];
> >  		kvm->arch.model.fac_list[i] = stfle_fac_list[i] &
> >  					      kvm_s390_fac_base[i];
> >  	}
> > +	for (i = 0; i < ARRAY_SIZE(kvm_s390_fac_ext); i++) {
> > +		kvm->arch.model.fac_mask[i] |= stfle_fac_list[i] &
> > +					       kvm_s390_fac_ext[i];
> > +	}
> 
> I like it better when it's all in one place, instead of having two loops

Hmm, it's the result of the arrays being different lengths now.

[...]

> > -	for (i = 0; i < 16; i++)
> > -		kvm_s390_fac_base[i] |=
> > -			stfle_fac_list[i] & nonhyp_mask(i);
> > +	for (i = 0; i < HMFAI_DWORDS; i++)
> > +		kvm_s390_fac_base[i] |= nonhyp_mask(i);
> 
> where did the stfle_fac_list[i] go?

I deleted it. That's what I meant by "Get rid of implicit double
anding of stfle_fac_list".
Besides it being redundant I didn't like it conceptually.
kvm_s390_fac_base specifies the facilities we support, regardless
if they're installed in the configuration. The hypervisor managed
ones are unconditionally declared via FACILITIES_KVM and we can add
the non hypervisor managed ones unconditionally, too.

> >  	r = __kvm_s390_init();
> >  	if (r)
> 


  reply	other threads:[~2023-11-06 11:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-03 17:30 [PATCH 0/4] KVM: s390: Fix minor bugs in STFLE shadowing Nina Schoetterl-Glausch
2023-11-03 17:30 ` [PATCH 1/4] KVM: s390: vsie: Fix STFLE interpretive execution identification Nina Schoetterl-Glausch
2023-11-03 18:12   ` Claudio Imbrenda
2023-11-03 18:32   ` David Hildenbrand
2023-11-03 17:30 ` [PATCH 2/4] KVM: s390: vsie: Fix length of facility list shadowed Nina Schoetterl-Glausch
2023-11-03 18:34   ` David Hildenbrand
2023-11-06 13:06     ` Nina Schoetterl-Glausch
2023-11-06 13:43       ` Heiko Carstens
2023-11-03 17:30 ` [PATCH 3/4] KVM: s390: cpu model: Use previously unused constant Nina Schoetterl-Glausch
2023-11-03 18:36   ` David Hildenbrand
2023-11-03 18:41     ` David Hildenbrand
2023-11-06 11:00       ` Nina Schoetterl-Glausch
2023-11-03 17:30 ` [PATCH 4/4] KVM: s390: Minor refactor of base/ext facility lists Nina Schoetterl-Glausch
2023-11-03 18:32   ` Claudio Imbrenda
2023-11-06 11:38     ` Nina Schoetterl-Glausch [this message]
2023-11-06 12:18       ` 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=44148ab315f28a6d77627675cbde26977418c5df.camel@linux.ibm.com \
    --to=nsg@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=dahi@linux.vnet.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@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=mimu@linux.vnet.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