[Qemu-devel] Interactive Boot Menu: New Fields in IPLB

[Qemu-devel] Interactive Boot Menu: New Fields in IPLB

[Collin L. Walling]

Hello,

I'd like to bring up a formal discussion regarding the utilization of 
reserved space
in the IPL Parameter Blocks for s390x guests. Particularly the following:

  * How should we approach "claiming" bytes so that we do not obstruct
    future development?
  * What would be "the best" location to store these new fields?

I've posted some relevant information regarding this feature below.


                       --- The Fields We Need To Store ---

Currently, we're utilizing 3 bytes out of a 77 byte reserved field in 
the IPLB for
CCW and SCSI. We do this because need a way to pass the Qemu command 
line options
for a boot menu (on/off and timeout) to the s390-ccw bios. We require 
only two
fields in the IPLB, totaling 3 bytes:

  * uint8_t boot_menu_flag
      o determines if we should show the menu or not

  * uint16_t boot_menu_timeout
      o stored as milliseconds
      o A max value of approx 65,000 gives us 65 seconds -- should be 
plenty
      o could potentially be reduced to one byte, and we store the value
        as seconds instead

Note: these fields *only*have value in a QEMU environment.


                   --- The Data We Have In Place Already ---

The following can be found in qemu/hw/s390x/ipl.h: (a similar structure 
exists
in qemu/pc-bios/s390-ccw/iplb.h)

struct IplBlockCcw {
     uint64_t netboot_start_addr;
     uint8_t  reserved0[74];        // <--- previously a 77 reserved field
     uint16_t boot_menu_timeout;    // new
     uint8_t  boot_menu_flag;       // new
     uint8_t  ssid;
     uint16_t devno;
     uint8_t  vm_flags;
     uint8_t  reserved3[3];
     uint32_t vm_parm_len;
     uint8_t  nss_name[8];
     uint8_t  vm_parm[64];
     uint8_t  reserved4[8];
} QEMU_PACKED;
typedef struct IplBlockCcw IplBlockCcw;

struct IplBlockFcp {
     uint8_t  reserved1[305 - 1];
     uint8_t  opt;
     uint8_t  reserved2[3];
     uint16_t reserved3;
     uint16_t devno;
     uint8_t  reserved4[4];
     uint64_t wwpn;
     uint64_t lun;
     uint32_t bootprog;
     uint8_t  reserved5[12];
     uint64_t br_lba;
     uint32_t scp_data_len;
     uint8_t  reserved6[260];
     uint8_t  scp_data[];
} QEMU_PACKED;
typedef struct IplBlockFcp IplBlockFcp;

struct IplBlockQemuScsi {
     uint32_t lun;
     uint16_t target;
     uint16_t channel;
     uint8_t  reserved0[74];        // <--- previously a 77 reserved field
     uint16_t boot_menu_timeout;    // new
     uint8_t  boot_menu_flag;       // new
     uint8_t  ssid;
     uint16_t devno;
} QEMU_PACKED;
typedef struct IplBlockQemuScsi IplBlockQemuScsi;

[...]

union IplParameterBlock {
     struct {
         uint32_t len;
         uint8_t  reserved0[3];
         uint8_t  version;
         uint32_t blk0_len;
         uint8_t  pbt;
         uint8_t  flags;
         uint16_t reserved01;
         uint8_t  loadparm[8];
         union {
             IplBlockCcw ccw;
             IplBlockFcp fcp;
             IplBlockQemuScsi scsi;
         };
     } QEMU_PACKED;
     struct {
         uint8_t  reserved1[110];
         uint16_t devno;
         uint8_t  reserved2[88];
         uint8_t  reserved_ext[4096 - 200];
     } QEMU_PACKED;
} QEMU_PACKED;
typedef union IplParameterBlock IplParameterBlock;

-----------------------------

Thanks for your time,
- Collin L Walling

Re: [Qemu-devel] Interactive Boot Menu: New Fields in IPLB

[Christian Borntraeger]

On 12/08/2017 12:56 AM, Collin L. Walling wrote:
> Hello,
> 
> I'd like to bring up a formal discussion regarding the utilization of reserved space
> in the IPL Parameter Blocks for s390x guests. Particularly the following:
> 
>  * How should we approach "claiming" bytes so that we do not obstruct
>    future development?

We need to talk to our architecture folks after all this is used across all operating systems.

Re: [Qemu-devel] Interactive Boot Menu: New Fields in IPLB

[Cornelia Huck]

On Thu, 7 Dec 2017 18:56:16 -0500
"Collin L. Walling" <walling@linux.vnet.ibm.com> wrote:

> Hello,
> 
> I'd like to bring up a formal discussion regarding the utilization of 
> reserved space
> in the IPL Parameter Blocks for s390x guests. Particularly the following:
> 
>   * How should we approach "claiming" bytes so that we do not obstruct
>     future development?
>   * What would be "the best" location to store these new fields?

As Christian said, you probably need to check with the architecture
folks whether you can get some fields reserved for your use case.

In general, having this anywhere in the reserved areas of the iplb
should probably be fine (we migrate the iplb in two mostly-opaque
blobs).

Re: [Qemu-devel] Interactive Boot Menu: New Fields in IPLB

[Cornelia Huck]

On Thu, 7 Dec 2017 18:56:16 -0500
"Collin L. Walling" <walling@linux.vnet.ibm.com> wrote:


>                        --- The Fields We Need To Store ---
> 
> Currently, we're utilizing 3 bytes out of a 77 byte reserved field in 
> the IPLB for
> CCW and SCSI. We do this because need a way to pass the Qemu command 
> line options
> for a boot menu (on/off and timeout) to the s390-ccw bios. We require 
> only two
> fields in the IPLB, totaling 3 bytes:

Hm, are we actually that constrained with space?

> 
>   * uint8_t boot_menu_flag
>       o determines if we should show the menu or not

Should be fine. I'd recommend something along the lines of
- bit 0: show a boot menu
- bit 1-7: reserved [for future use]

> 
>   * uint16_t boot_menu_timeout
>       o stored as milliseconds
>       o A max value of approx 65,000 gives us 65 seconds -- should be 
> plenty

65 seconds should be enough for everyone?

:)

>       o could potentially be reduced to one byte, and we store the value
>         as seconds instead

As said, do we really need to worry about the space this is using up
here?

> 
> Note: these fields *only*have value in a QEMU environment.

Re: [Qemu-devel] Interactive Boot Menu: New Fields in IPLB

[David Hildenbrand]

On 08.12.2017 00:56, Collin L. Walling wrote:
> Hello,
> 
> I'd like to bring up a formal discussion regarding the utilization of 
> reserved space
> in the IPL Parameter Blocks for s390x guests. Particularly the following:
> 
>   * How should we approach "claiming" bytes so that we do not obstruct
>     future development?
>   * What would be "the best" location to store these new fields?
> 
> I've posted some relevant information regarding this feature below.
> 
> 
>                        --- The Fields We Need To Store ---
> 
> Currently, we're utilizing 3 bytes out of a 77 byte reserved field in 
> the IPLB for
> CCW and SCSI. We do this because need a way to pass the Qemu command 
> line options
> for a boot menu (on/off and timeout) to the s390-ccw bios. We require 
> only two
> fields in the IPLB, totaling 3 bytes:
> 
>   * uint8_t boot_menu_flag
>       o determines if we should show the menu or not
> 
>   * uint16_t boot_menu_timeout
>       o stored as milliseconds
>       o A max value of approx 65,000 gives us 65 seconds -- should be 

1. Why on earth milliseconds. I'd rather have it remain open for 5
minutes than 1ms. 1s should really be a sufficient granularity.

2. Why not combine everything in one field?

0x00000000 -> Don't show
0x00000001 -> Show, wait 1s
...
0xffff0000 .. 0xfffffffe -> Reserved
0xffffffff -> Show, wait forever

We could add another special value for "use defaults from zipl"

-- 

Thanks,

David / dhildenb