On 28/02/2026 03.15, Zhuoying Cai wrote:
On 2/27/26 7:58 AM, Thomas Huth wrote:
On 12/02/2026 21.43, Zhuoying Cai wrote:
DIAG 320 subcode 1 provides information needed to determine
the amount of storage to store one or more certificates from the
certificate store.
Upon successful completion, this subcode returns information of the current
cert store, such as the number of certificates stored and allowed in the cert
store, amount of space may need to be allocate to store a certificate,
etc for verification-certificate blocks (VCBs).
The subcode value is denoted by setting the left-most bit
of an 8-byte field.
The verification-certificate-storage-size block (VCSSB) contains
the output data when the operation completes successfully. A VCSSB
length of 4 indicates that no certificate are available in the cert
store.
Signed-off-by: Zhuoying Cai <[email protected]>
Reviewed-by: Farhan Ali <[email protected]>
Reviewed-by: Collin Walling <[email protected]>
---
...
diff --git a/include/hw/s390x/ipl/diag320.h b/include/hw/s390x/ipl/diag320.h
index aa04b699c6..6e4779c699 100644
--- a/include/hw/s390x/ipl/diag320.h
+++ b/include/hw/s390x/ipl/diag320.h
@@ -11,10 +11,32 @@
#define S390X_DIAG320_H
#define DIAG_320_SUBC_QUERY_ISM 0
+#define DIAG_320_SUBC_QUERY_VCSI 1
#define DIAG_320_RC_OK 0x0001
#define DIAG_320_RC_NOT_SUPPORTED 0x0102
+#define DIAG_320_RC_INVAL_VCSSB_LEN 0x0202
#define DIAG_320_ISM_QUERY_SUBCODES 0x80000000
+#define DIAG_320_ISM_QUERY_VCSI 0x40000000
+
+#define VCSSB_NO_VC 4
+#define VCSSB_MIN_LEN 128
+#define VCE_HEADER_LEN 128
+#define VCB_HEADER_LEN 64
+
+struct VCStorageSizeBlock {
+ uint32_t length;
+ uint8_t reserved0[3];
+ uint8_t version;
+ uint32_t reserved1[6];
+ uint16_t total_vc_ct;
+ uint16_t max_vc_ct;
+ uint32_t reserved3[11];
+ uint32_t max_single_vcb_len;
+ uint32_t total_vcb_len;
+ uint32_t reserved4[10];
+};
+typedef struct VCStorageSizeBlock VCStorageSizeBlock;
Since this API between QEMU and the guest, maybe add a
QEMU_BUILD_BUG_ON(sizeof(VCStorageSizeBlock) != ...);
here to make sure that there is no accidential padding.
(should not happen since field are naturally aligned, but better be safe
than sorry?)
Please correct me if I’m wrong. QEMU_BUILD_BUG_ON() is a QEMU-specific
macro and is not accessible from the guest, so using it here would cause
a compile error. I’m not aware of similar checks being used on the guest
side. Would QEMU_BUILD_BUG_ON() still be appropriate in this case, or is
there a better way to ensure that no unintended padding is introduced?
Ah, you're right, my bad, sorry, we don't define QEMU_BUILD_BUG_ON for the
s390-ccw bios, indeed. We could likely define it there, too, like we do for
QEMU_PACKED already, but for the time being, it's ok to not add a
QEMU_BUILD_BUG_ON here.
Thomas
