From: "Kalra, Ashish" <ashish.kalra@amd.com>
To: Kim Phillips <kim.phillips@amd.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Cc: Neeraj.Upadhyay@amd.com, aik@amd.com, akpm@linux-foundation.org,
ardb@kernel.org, arnd@arndb.de, bp@alien8.de, corbet@lwn.net,
dave.hansen@linux.intel.com, davem@davemloft.net, hpa@zytor.com,
john.allen@amd.com, kvm@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, michael.roth@amd.com,
mingo@redhat.com, nikunj@amd.com, paulmck@kernel.org,
pbonzini@redhat.com, rostedt@goodmis.org, seanjc@google.com,
tglx@linutronix.de, thomas.lendacky@amd.com, x86@kernel.org
Subject: Re: [PATCH v7 0/7] Add SEV-SNP CipherTextHiding feature support
Date: Mon, 18 Aug 2025 18:58:08 -0500 [thread overview]
Message-ID: <76ac003b-2502-459a-bf94-55f7b15e2e1b@amd.com> (raw)
In-Reply-To: <a16f1420-fe20-4c3c-9b75-806b1da22336@amd.com>
On 8/18/2025 6:23 PM, Kim Phillips wrote:
> On 8/18/25 3:39 PM, Kalra, Ashish wrote:
>> On 8/18/2025 2:38 PM, Kim Phillips wrote:
>>> On 8/18/25 2:16 PM, Kalra, Ashish wrote:
>>>> On 8/16/2025 3:39 AM, Herbert Xu wrote:
>>>>> On Mon, Aug 11, 2025 at 08:30:25PM +0000, Ashish Kalra wrote:
>>>>>> Hi Herbert, can you please merge patches 1-5.
>>>>>>
>>>>>> Paolo/Sean/Herbert, i don't know how do you want handle cross-tree merging
>>>>>> for patches 6 & 7.
>>>>> These patches will be at the base of the cryptodev tree for 6.17
>>>>> so it could be pulled into another tree without any risks.
>>>>>
>>>>> Cheers,
>>>> Thanks Herbert for pulling in patches 1-5.
>>>>
>>>> Paolo, can you please merge patches 6 and 7 into the KVM tree.
>>> Hi Ashish,
>>>
>>> I have pending comments on patch 7:
>>>
>>> https://lore.kernel.org/kvm/e32a48dc-a8f7-4770-9e2f-1f3721872a63@amd.com/
>>>
>>> If still not welcome, can you say why you think:
>>>
>>> 1. The ciphertext_hiding_asid_nr variable is necessary
>> I prefer safe coding, and i don't want to update max_snp_asid, until i am sure there are no sanity
>> check failures and that's why i prefer using a *temp* variable and then updating max_snp_asid when i
>> am sure all sanity checks have been done.
>>
>> Otherwise, in your case you are updating max_snp_asid and then rolling it back in case of sanity check
>> failures, i don't like that.
>
> Item (1):
>
> The rollback is in a single place, and the extra variable's existence can be avoided, or, at least have 'temp' somewhere in its name.
>
> FWIW, any "Safe coding" practices should have been performed prior to the submission of the patch, IMO.
>
>>> 2. The isdigit(ciphertext_hiding_asids[0])) check is needed when it's immediately followed by kstrtoint which effectively makes the open-coded isdigit check redundant?
>> isdigit() is a MACRO compared to kstrtoint() call, it is more optimal to do an inline check and avoid
>> calling kstrtoint() if the parameter is not a number.
>
> Item (2):
>
> This is module initialization code, it's better optimized for readability than for performance. As a reader of the code, I'm constantly wondering why the redundancy exists, and am sure it is made objectively easier to read if the isdigit() check were removed.
>
>>> 3. Why the 'invalid_parameter:' label referenced by only one goto statement can't be folded and removed.
>> This is for understandable code flow :
>>
>> 1). Check module parameter is set by user.
>> 2). Check ciphertext_hiding_feature enabled.
>> 3). Check if parameter is numeric.
>> Sanity checks on numeric parameter
>> If checks fail goto invalid_parameter
>> 4). Check if parameter is the string "max".
>> 5). Set max_snp_asid and min_sev_es_asid.
>> 6). Fall-through to invalid parameter.
>> invalid_parameter:
>>
>> This is overall a more understandable code flow.
>
> Item (3):
>
> That's not how your original v7 flows, but I do now see the non-obvious fall-through from the else if (...'max'...). I believe I am not alone in missing that, and that a comment would have helped. Also, the 'else' isn't required
>
> Flow readability-wise, comparing the two, after the two common if()s, your original v7 goes:
>
> {
> ...
> if (isdigit() {
> if (kstrtoint())
> goto invalid_parameter
> if (temporary variable >= min_sev_asid) {
> pr_warn()
> return false;
> } else if (..."max"...) {
> temporary variable = ...
> /* non-obvious fallthrough to invalid_parameter iff temporary_variable == 0 */
> }
>
> if (temporary variable) {
> max_snp_asid = ...
> min_sev_es_asid = ...
> pr_info(..."enabled"...)
> return true;
> }
>
> invalid_parameter:
> pr_warn()
> return false;
> }
>
> vs the result of my latest diff:
>
> {
> ...
> if (..."max"...) {
> max_snp_asid =
> min_sev_es_asid = ...
> return true;
> }
>
> if (kstrtoint()) {
> pr_warn()
> return false
> }
>
> if (max_snp_asid < 1 || >= min_sev_asid) {
> pr_warn()
> max_snp_asid = /* rollback */
> return false;
> }
>
> min_sev_es_asid = ...
>
> return true;
> }
>
> So, just from an outright flow perspective, I believe my latest diff is objectively easier to follow.
>
All the above are your opinions and i don't agree with them and my patch is bug-free and simple and easy to understand and works perfectly, and i am not making any more changes to it.
Thanks,
Ashish
>> Again, this is just a module parameter checking function and not something which will affect runtime performance by eliminating a single temporary variable or jump label.
> With this statement, you self-contradict your rationale to keep your version of the above to Item (2): "isdigit() is a MACRO compared to kstrtoint() call, it is more optimal to do an inline check and avoid calling kstrtoint() if the parameter is not a number". If not willing to take my latest diff as-is, I really would like to see:
>
> Item (1)'s variable get a temporary-sounding name,
> item (2)'s the isdigit() check (and thus a whole indentation level) removed, and
> item (3)'s flow reconsidered given the (IMO objective) readability enhancement.
>
> Thanks,
>
> Kim
>
next prev parent reply other threads:[~2025-08-18 23:58 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-21 14:12 Ashish Kalra
2025-07-21 14:12 ` [PATCH v7 1/7] crypto: ccp - New bit-field definitions for SNP_PLATFORM_STATUS command Ashish Kalra
2025-07-21 14:12 ` [PATCH v7 2/7] crypto: ccp - Cache SEV platform status and platform state Ashish Kalra
2025-07-21 14:13 ` [PATCH v7 3/7] crypto: ccp - Add support for SNP_FEATURE_INFO command Ashish Kalra
2025-07-21 14:13 ` [PATCH v7 4/7] crypto: ccp - Introduce new API interface to indicate SEV-SNP Ciphertext hiding feature Ashish Kalra
2025-07-21 14:13 ` [PATCH v7 5/7] crypto: ccp - Add support to enable CipherTextHiding on SNP_INIT_EX Ashish Kalra
2025-07-21 14:14 ` [PATCH v7 6/7] KVM: SEV: Introduce new min,max sev_es and sev_snp asid variables Ashish Kalra
2025-07-21 14:14 ` [PATCH v7 7/7] KVM: SEV: Add SEV-SNP CipherTextHiding support Ashish Kalra
2025-07-25 17:58 ` Kim Phillips
2025-07-25 18:28 ` Tom Lendacky
2025-07-25 18:46 ` Kalra, Ashish
2025-08-12 12:06 ` Kim Phillips
2025-08-12 14:40 ` Kalra, Ashish
2025-08-12 16:45 ` Kim Phillips
2025-08-12 18:29 ` Kalra, Ashish
2025-08-12 18:40 ` Kim Phillips
2025-08-12 18:52 ` Kalra, Ashish
2025-08-12 19:11 ` Kim Phillips
2025-08-12 19:38 ` Kalra, Ashish
2025-08-12 23:30 ` Kim Phillips
2025-08-14 11:54 ` Kim Phillips
2025-08-11 20:30 ` [PATCH v7 0/7] Add SEV-SNP CipherTextHiding feature support Ashish Kalra
2025-08-16 8:39 ` Herbert Xu
2025-08-18 19:16 ` Kalra, Ashish
2025-08-18 19:38 ` Kim Phillips
2025-08-18 20:39 ` Kalra, Ashish
2025-08-18 23:23 ` Kim Phillips
2025-08-18 23:58 ` Kalra, Ashish [this message]
2025-08-19 7:59 ` Borislav Petkov
2025-08-20 0:05 ` Sean Christopherson
2025-08-20 1:17 ` Kalra, Ashish
2025-08-20 15:02 ` Sean Christopherson
2025-08-16 9:29 ` Herbert Xu
2025-09-08 20:16 ` Sean Christopherson
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=76ac003b-2502-459a-bf94-55f7b15e2e1b@amd.com \
--to=ashish.kalra@amd.com \
--cc=Neeraj.Upadhyay@amd.com \
--cc=aik@amd.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=john.allen@amd.com \
--cc=kim.phillips@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=rostedt@goodmis.org \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®