On 7/3/26 1:00 PM, Zhuoying Cai wrote:
> Rework s390_ipl_map_iplb_chain to always allocate maximum memory for
> the IPLB chain, regardless of the number of boot devices. This space
> is also used to store certificates during secure boot, providing a
> safe location for certificates until the kernel reads them during boot.
>
> Rename next_iplb to ipl_data to better reflect its multiple purposes:
> storing both IPLB chains and certificate data.
>
> Signed-off-by: Zhuoying Cai <[email protected]>
> Reviewed-by: Eric Farman <[email protected]>
...
> +QEMU_BUILD_BUG_MSG(sizeof(IplParameterBlock) * (MAX_BOOT_DEVS - 1) !=
> CERT_BUF_SIZE,
> + "certificate buffer size is wrong");
>
> static void update_machine_ipl_properties(IplParameterBlock *iplb)
> {
> diff --git a/include/hw/s390x/ipl/qipl.h b/include/hw/s390x/ipl/qipl.h
> index a2180719b1..58329fb5bc 100644
> --- a/include/hw/s390x/ipl/qipl.h
> +++ b/include/hw/s390x/ipl/qipl.h
> @@ -42,6 +42,7 @@ typedef enum S390IplType S390IplType;
> #define S390_IPLB_MAX_LEN 4096
>
> #define MAX_CERTIFICATES 64
> +#define CERT_BUF_SIZE (7 * 4096)
Isn't the idea here to just limit to the minimum amount of space
necessary to accommodate the largest number of possible boot
devices?
In other words, can this also use MAX_BOOT_DEVS e.g.
#define CERT_BUF_SIZE ((MAX_BOOT_DEVS - 1) * 4096)
Then the bug message above would only fire if we change the
IplParameterBlock size, a far less obvious (and less likely) thing to
happen.
Or is there some other reason we cannot exceed 7 despite what QEMU
might request?
With that change (or an explanation on why we cannot and must bug out
if MAX_BOOT_DEVS != 8 || sizeof(IplParameterBlock) != 4K)
Reviewed-by: Matthew Rosato <[email protected]>
