[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0d90c2cb-e0e9-a112-1c85-9aa8fdd54311@linux.ibm.com>
Date: Mon, 27 Jun 2022 15:29:13 +0200
From: Pierre Morel <pmorel@...ux.ibm.com>
To: Janosch Frank <frankja@...ux.ibm.com>, kvm@...r.kernel.org
Cc: linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
borntraeger@...ibm.com, cohuck@...hat.com, david@...hat.com,
thuth@...hat.com, imbrenda@...ux.ibm.com, hca@...ux.ibm.com,
gor@...ux.ibm.com, wintera@...ux.ibm.com, seiden@...ux.ibm.com,
nrb@...ux.ibm.com
Subject: Re: [PATCH v10 1/3] KVM: s390: ipte lock for SCA access should be
contained in KVM
On 6/24/22 07:47, Janosch Frank wrote:
> On 6/20/22 14:54, Pierre Morel wrote:
>> We can check if SIIF is enabled by testing the sclp_info struct
>> instead of testing the sie control block eca variable.
>> sclp.has_ssif is the only requirement to set ECA_SII anyway
>> so we can go straight to the source for that.
>
>
> The subject and commit description don't fit together.
> You're doing two things in this patch and only describe one of them.
>
> I'd suggest something like this:
>
> KVM: s390: Cleanup ipte lock access and SIIF facility checks
>
> We can check if SIIF is enabled by testing the sclp_info struct instead
> of testing the sie control block eca variable as that facility is always
> enabled if available.
>
> Also let's cleanup all the ipte related struct member accesses which
> currently happen by referencing the KVM struct via the VCPU struct.
> Making the KVM struct the parameter to the ipte_* functions removes one
> level of indirection which makes the code more readable.
>
OK done.
>
> Other than that I'm happy with this patch.
Thanks,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
Powered by blists - more mailing lists