All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhuoying Cai <zycai@linux.ibm.com>
To: Collin Walling <walling@linux.ibm.com>,
	thuth@redhat.com, berrange@redhat.com,
	richard.henderson@linaro.org, david@redhat.com,
	pbonzini@redhat.com, jrossi@linux.ibm.com, qemu-s390x@nongnu.org,
	qemu-devel@nongnu.org
Cc: jjherne@linux.ibm.com, pasic@linux.ibm.com,
	borntraeger@linux.ibm.com, farman@linux.ibm.com,
	mjrosato@linux.ibm.com, iii@linux.ibm.com
Subject: Re: [PATCH v4 19/28] pc-bios/s390-ccw: Refactor zipl_load_segment function
Date: Tue, 15 Jul 2025 11:59:13 -0400	[thread overview]
Message-ID: <310f1563-e04a-4aa2-aed1-ee631676c4a0@linux.ibm.com> (raw)
In-Reply-To: <be952290-0791-41e3-bfc7-a22eecfe97d6@linux.ibm.com>

On 7/14/25 6:10 PM, Collin Walling wrote:
> On 7/11/25 5:10 PM, Zhuoying Cai wrote:
>> Make the address variable a parameter of zipl_load_segment and return
>> segment length.
> 
> There's mixed use of the term "comp_len" and "segment length".  Since
> the context here is "zipl_load_segment", perhaps the variable should be
> "seg_len"?
> 
>>
>> Modify this function for reuse in the next patch, which allows
>> loading segment or signature data to the destination memory address.
> 
> The function is still loading a segment from the disk regardless if it's
> a signature or something else.  I'd suggest rewording the above for more
> precision about the change:
> 
> "Modify this function to allow the caller to specify a memory address
> where segment data should be loaded into."
> 
>>
>> Add a comp_len variable to store the length of a segment and return this
>> variable in zipl_load_segment.
> 
> This sentence is redundant since the change in the return behavior is
> mentioned in the first sentence.
> 
>>
>> comp_len variable is necessary to store the calculated segment length and
>> is used during signature verification. Return the length on success, or
>> a negative return code on failure.
>>
>> Signed-off-by: Zhuoying Cai <zycai@linux.ibm.com>
> 
> Bit of a nit: technically this isn't refactoring since the function's
> behavior has changed (new param and different return meaning).  Change
> the commit header from "refactor" to "rework" or something akin to that.
> 
>> ---
>>  pc-bios/s390-ccw/bootmap.c | 12 +++++++-----
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
>> index ced5190888..2513e6c131 100644
>> --- a/pc-bios/s390-ccw/bootmap.c
>> +++ b/pc-bios/s390-ccw/bootmap.c
>> @@ -613,19 +613,18 @@ static int ipl_eckd(void)
>>   * IPL a SCSI disk
>>   */
>>  
>> -static int zipl_load_segment(ComponentEntry *entry)
>> +static int zipl_load_segment(ComponentEntry *entry, uint64_t address)
> 
> The return value meaning of this function has changed from being "< 0
> means error, 0 is okay" to "< 0 means error, otherwise the total size of
> the component is returned".  Please add a comment above this function to
> describe its return behavior so it's easy for future developers to
> understand it.
> 
>>  {
>>      const int max_entries = (MAX_SECTOR_SIZE / sizeof(ScsiBlockPtr));
>>      ScsiBlockPtr *bprs = (void *)sec;
>>      const int bprs_size = sizeof(sec);
>>      block_number_t blockno;
>> -    uint64_t address;
>>      int i;
>>      char err_msg[] = "zIPL failed to read BPRS at 0xZZZZZZZZZZZZZZZZ";
>>      char *blk_no = &err_msg[30]; /* where to print blockno in (those ZZs) */
>> +    int comp_len = 0;
>>  
>>      blockno = entry->data.blockno;
>> -    address = entry->compdat.load_addr;
>>  
>>      debug_print_int("loading segment at block", blockno);
>>      debug_print_int("addr", address);
>> @@ -662,6 +661,9 @@ static int zipl_load_segment(ComponentEntry *entry)
>>                   */
>>                  break;
>>              }
>> +
>> +            comp_len += bprs->size * (bprs[i].blockct + 1);
>> +
> 
> I'm confused by the arithmetic here.  Why is size multiplied by the
> block count?  Won't that artificially inflate the value representing the
> size of the component?  What's the reason that comp_len += bprs->size
> isn't sufficient?
> 

A component table entry points to a segment table, which holds pointers
to code segments loaded into contiguous memory.

Since segments can vary in length, the block count field may be nonzero.

Block size indicates the number of bytes in a single logical block, so
the total component size is the block size multiplied by the block count.

>>              address = virtio_load_direct(cur_desc[0], cur_desc[1], 0,
>>                                           (void *)address);
>>              if (!address) {
>> @@ -671,7 +673,7 @@ static int zipl_load_segment(ComponentEntry *entry)
>>          }
>>      } while (blockno);
>>  
>> -    return 0;
>> +    return comp_len;
>>  }
>>  
>>  static int zipl_run_normal(ComponentEntry *entry, uint8_t *tmp_sec)
>> @@ -685,7 +687,7 @@ static int zipl_run_normal(ComponentEntry *entry, uint8_t *tmp_sec)
>>              continue;
>>          }
>>  
>> -        if (zipl_load_segment(entry)) {
>> +        if (zipl_load_segment(entry, entry->compdat.load_addr) < 0) {
>>              return -1;
>>          }
>>  
> 



  reply	other threads:[~2025-07-15 16:38 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-11 21:10 [PATCH v4 00/28] Secure IPL Support for SCSI Scheme of virtio-blk/virtio-scsi Devices Zhuoying Cai
2025-07-11 21:10 ` [PATCH v4 01/28] Add boot-certificates to s390-ccw-virtio machine type option Zhuoying Cai
2025-07-22 15:56   ` Daniel P. Berrangé
2025-07-11 21:10 ` [PATCH v4 02/28] crypto/x509-utils: Add helper functions for certificate store Zhuoying Cai
2025-07-22 16:06   ` Daniel P. Berrangé
2025-07-11 21:10 ` [PATCH v4 03/28] hw/s390x/ipl: Create " Zhuoying Cai
2025-07-22 16:14   ` Daniel P. Berrangé
2025-07-11 21:10 ` [PATCH v4 04/28] s390x: Guest support for Certificate Store Facility (CS) Zhuoying Cai
2025-07-21 21:30   ` Collin Walling
2025-07-23 20:15     ` Collin Walling
2025-07-11 21:10 ` [PATCH v4 05/28] s390x/diag: Introduce DIAG 320 for certificate store facility Zhuoying Cai
2025-07-21 21:26   ` Collin Walling
2025-07-21 21:39     ` Collin Walling
2025-07-22 21:08       ` Collin Walling
2025-07-23 17:50     ` Eric Farman
2025-07-11 21:10 ` [PATCH v4 06/28] s390x/diag: Refactor address validation check from diag308_parm_check Zhuoying Cai
2025-07-11 21:10 ` [PATCH v4 07/28] s390x/diag: Implement DIAG 320 subcode 1 Zhuoying Cai
2025-07-23 20:17   ` Eric Farman
2025-07-28 22:01     ` Zhuoying Cai
2025-07-23 22:15   ` Collin Walling
2025-07-23 22:20     ` Collin Walling
2025-07-11 21:10 ` [PATCH v4 08/28] crypto/x509-utils: Add helper functions for DIAG 320 subcode 2 Zhuoying Cai
2025-07-22 16:20   ` Daniel P. Berrangé
2025-07-11 21:10 ` [PATCH v4 09/28] s390x/diag: Implement " Zhuoying Cai
2025-07-22 16:23   ` Daniel P. Berrangé
2025-07-28 20:59   ` Collin Walling
2025-07-29 18:18     ` Zhuoying Cai
2025-07-29 18:56       ` Collin Walling
2025-07-11 21:10 ` [PATCH v4 10/28] s390x/diag: Introduce DIAG 508 for secure IPL operations Zhuoying Cai
2025-07-11 21:10 ` [PATCH v4 11/28] crypto/x509-utils: Add helper functions for DIAG 508 subcode 1 Zhuoying Cai
2025-07-22 16:26   ` Daniel P. Berrangé
2025-07-11 21:10 ` [PATCH v4 12/28] s390x/diag: Implement DIAG 508 subcode 1 for signature verification Zhuoying Cai
2025-07-11 21:10 ` [PATCH v4 13/28] pc-bios/s390-ccw: Introduce IPL Information Report Block (IIRB) Zhuoying Cai
2025-07-11 21:10 ` [PATCH v4 14/28] pc-bios/s390-ccw: Define memory for IPLB and convert IPLB to pointers Zhuoying Cai
2025-07-11 21:10 ` [PATCH v4 15/28] hw/s390x/ipl: Add IPIB flags to IPL Parameter Block Zhuoying Cai
2025-07-11 21:10 ` [PATCH v4 16/28] hw/s390x/ipl: Set iplb->len to maximum length of " Zhuoying Cai
2025-07-11 21:10 ` [PATCH v4 17/28] s390x: Guest support for Secure-IPL Facility Zhuoying Cai
2025-07-14 20:33   ` Collin Walling
2025-07-11 21:10 ` [PATCH v4 18/28] pc-bios/s390-ccw: Refactor zipl_run() Zhuoying Cai
2025-07-14 20:53   ` Collin Walling
2025-07-11 21:10 ` [PATCH v4 19/28] pc-bios/s390-ccw: Refactor zipl_load_segment function Zhuoying Cai
2025-07-14 22:10   ` Collin Walling
2025-07-15 15:59     ` Zhuoying Cai [this message]
2025-07-15 21:48       ` Collin Walling
2025-07-11 21:10 ` [PATCH v4 20/28] pc-bios/s390-ccw: Add signature verification for secure IPL in audit mode Zhuoying Cai
2025-07-11 22:50   ` Collin Walling
2025-07-14 14:54     ` Jared Rossi
2025-07-14 15:34       ` Thomas Huth
2025-07-14 17:46         ` Collin Walling
2025-07-21 21:50     ` Zhuoying Cai
2025-07-28 21:05       ` Collin Walling
2025-07-11 21:10 ` [PATCH v4 21/28] s390x: Guest support for Secure-IPL Code Loading Attributes Facility (SCLAF) Zhuoying Cai
2025-07-14 22:13   ` Collin Walling
2025-07-11 21:10 ` [PATCH v4 22/28] pc-bios/s390-ccw: Add additional security checks for secure boot Zhuoying Cai
2025-07-11 21:10 ` [PATCH v4 23/28] Add secure-boot to s390-ccw-virtio machine type option Zhuoying Cai
2025-07-11 21:11 ` [PATCH v4 24/28] hw/s390x/ipl: Set IPIB flags for secure IPL Zhuoying Cai
2025-07-11 21:11 ` [PATCH v4 25/28] pc-bios/s390-ccw: Handle true secure IPL mode Zhuoying Cai
2025-07-11 21:11 ` [PATCH v4 26/28] pc-bios/s390-ccw: Handle secure boot with multiple boot devices Zhuoying Cai
2025-07-22 16:28   ` Daniel P. Berrangé
2025-07-11 21:11 ` [PATCH v4 27/28] hw/s390x/ipl: Handle secure boot without specifying a boot device Zhuoying Cai
2025-07-11 21:11 ` [PATCH v4 28/28] docs: Add secure IPL documentation Zhuoying Cai
2025-07-21 19:13   ` Collin Walling

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=310f1563-e04a-4aa2-aed1-ee631676c4a0@linux.ibm.com \
    --to=zycai@linux.ibm.com \
    --cc=berrange@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=jrossi@linux.ibm.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.com \
    --cc=walling@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.