linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kim Phillips <kim.phillips@amd.com>
To: "Kalra, Ashish" <ashish.kalra@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:23:53 -0500	[thread overview]
Message-ID: <a16f1420-fe20-4c3c-9b75-806b1da22336@amd.com> (raw)
In-Reply-To: <c17990ac-30b2-4bdc-b31a-811af6052782@amd.com>

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.

> 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:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-21 14:12 [PATCH v7 0/7] Add SEV-SNP CipherTextHiding feature support 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 [this message]
2025-08-18 23:58             ` Kalra, Ashish
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

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=a16f1420-fe20-4c3c-9b75-806b1da22336@amd.com \
    --to=kim.phillips@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=ashish.kalra@amd.com \
    --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=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;
as well as URLs for NNTP newsgroup(s).