mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
> 

  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®