* [Qemu-devel] Interactive Boot Menu: New Fields in IPLB
@ 2017-12-07 23:56 Collin L. Walling
2017-12-08 8:26 ` Christian Borntraeger
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Collin L. Walling @ 2017-12-07 23:56 UTC (permalink / raw)
To: qemu-devel, qemu-s390x
Cc: Christian Borntraeger, Viktor Mihajlovski, Thomas Huth,
Cornelia Huck, David Hildenbrand
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] Interactive Boot Menu: New Fields in IPLB
2017-12-07 23:56 [Qemu-devel] Interactive Boot Menu: New Fields in IPLB Collin L. Walling
@ 2017-12-08 8:26 ` Christian Borntraeger
2017-12-08 10:14 ` Cornelia Huck
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Christian Borntraeger @ 2017-12-08 8:26 UTC (permalink / raw)
To: Collin L. Walling, qemu-devel, qemu-s390x
Cc: Viktor Mihajlovski, Thomas Huth, Cornelia Huck, David Hildenbrand
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] Interactive Boot Menu: New Fields in IPLB
2017-12-07 23:56 [Qemu-devel] Interactive Boot Menu: New Fields in IPLB Collin L. Walling
2017-12-08 8:26 ` Christian Borntraeger
@ 2017-12-08 10:14 ` Cornelia Huck
2017-12-08 10:19 ` Cornelia Huck
2017-12-08 11:59 ` David Hildenbrand
3 siblings, 0 replies; 5+ messages in thread
From: Cornelia Huck @ 2017-12-08 10:14 UTC (permalink / raw)
To: Collin L. Walling
Cc: qemu-devel, qemu-s390x, Christian Borntraeger, Viktor Mihajlovski,
Thomas Huth, David Hildenbrand
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).
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] Interactive Boot Menu: New Fields in IPLB
2017-12-07 23:56 [Qemu-devel] Interactive Boot Menu: New Fields in IPLB Collin L. Walling
2017-12-08 8:26 ` Christian Borntraeger
2017-12-08 10:14 ` Cornelia Huck
@ 2017-12-08 10:19 ` Cornelia Huck
2017-12-08 11:59 ` David Hildenbrand
3 siblings, 0 replies; 5+ messages in thread
From: Cornelia Huck @ 2017-12-08 10:19 UTC (permalink / raw)
To: Collin L. Walling
Cc: qemu-devel, qemu-s390x, Christian Borntraeger, Viktor Mihajlovski,
Thomas Huth, David Hildenbrand
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] Interactive Boot Menu: New Fields in IPLB
2017-12-07 23:56 [Qemu-devel] Interactive Boot Menu: New Fields in IPLB Collin L. Walling
` (2 preceding siblings ...)
2017-12-08 10:19 ` Cornelia Huck
@ 2017-12-08 11:59 ` David Hildenbrand
3 siblings, 0 replies; 5+ messages in thread
From: David Hildenbrand @ 2017-12-08 11:59 UTC (permalink / raw)
To: Collin L. Walling, qemu-devel, qemu-s390x
Cc: Christian Borntraeger, Viktor Mihajlovski, Thomas Huth,
Cornelia Huck
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-12-08 11:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-12-07 23:56 [Qemu-devel] Interactive Boot Menu: New Fields in IPLB Collin L. Walling
2017-12-08 8:26 ` Christian Borntraeger
2017-12-08 10:14 ` Cornelia Huck
2017-12-08 10:19 ` Cornelia Huck
2017-12-08 11:59 ` David Hildenbrand
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).