x86: Manage BIOS boot menu via command line

PATCH In review Jan Kiszka 6 participants 11 messages Dec 18, 2008

Share & tools

Jan Kiszka

author

2008-12-18 13:04 UTC #0 lore raw

PATCH 1/1 x86: Manage BIOS boot menu via command line

When booting a guest from the command line, you normally do not need the interactive boot menu with its 3 s waiting that someone might press F12. So this patch introduces a mechanism to enable the boot menu only on demand, ie. when the user provided the command line switch -bootmenu. This reduces boot times to their original dimension.

The host-guest interface used here is CMOS RAM byte 0x60. If it is non-zero, the guest BIOS will skip the F12 delay, keeping the previous behavior in case the host does not support it. -bootmenu was chosen in favor of -boot as the syntax of the latter is not easily and cleanly extensible.

Signed-off-by Jan Kiszka <[email protected]>

---

 hw/pc.c                                       |    3 +++
 pc-bios/bios-pq/0006_optional-boot-menu.patch |   19 +++++++++++++++++++
 pc-bios/bios-pq/series                        |    1 +
 sysemu.h                                      |    1 +
 vl.c                                          |    9 +++++++++
 5 files changed, 33 insertions(+), 0 deletions(-)
 create mode 100644 pc-bios/bios-pq/0006_optional-boot-menu.patch

hw/pc.c +3 -0

index 64c08a4..11576d1 100644
@@ -348,6 +348,9 @@ static void cmos_init(ram_addr_t ram_size, ram_addr_t above_4g_mem_size,
         }
     }
     rtc_set_memory(s, 0x39, val);
+
+    if (!bootmenu)
+        rtc_set_memory(s, 0x60, 1);
 }
 
 void ioport_set_a20(int enable)

pc-bios/bios-pq/0006_optional-boot-menu.patch new file +19 -0

new file mode 100644
index 0000000..bbe5753
@@ -0,0 +1,19 @@
+Make interactive boot menu optional.
+
+Signed-off-by: Jan Kiszka <[email protected]>
+
+diff --git a/bios/rombios.c b/bios/rombios.c
+index 123672f..7ce5b6c 100644
+--- a/bios/rombios.c
++++ b/bios/rombios.c
+@@ -2026,6 +2026,10 @@ interactive_bootkey()
+   Bit16u ss = get_SS();
+   Bit16u valid_choice = 0;
+ 
++  /* QEMU sets CMOS byte 0x60 to non-zero if the boot menu should be skipped */
++  if (inb_cmos(0x60))
++    return;
++
+   while (check_for_keystroke())
+     get_keystroke();
+

pc-bios/bios-pq/series +1 -0

index beff2c6..9c7b6a1 100644
@@ -3,3 +3,4 @@
 0003_smp-startup-poll.patch
 0004_no-stack-protector.patch
 0005_hpet.patch
+0006_optional-boot-menu.patch

sysemu.h +1 -0

index 94cffaf..1ecaed9 100644
@@ -99,6 +99,7 @@ extern int semihosting_enabled;
 extern int old_param;
 extern const char *bootp_filename;
 extern DisplayState display_state;
+extern int bootmenu;
 
 #ifdef USE_KQEMU
 extern int kqemu_allowed;

vl.c +9 -0

index 66dd975..fea9293 100644
@@ -218,6 +218,7 @@ int no_quit = 0;
 CharDriverState *serial_hds[MAX_SERIAL_PORTS];
 CharDriverState *parallel_hds[MAX_PARALLEL_PORTS];
 #ifdef TARGET_I386
+int bootmenu = 0;
 int win2k_install_hack = 0;
 #endif
 int usb_enabled = 0;

@@ -3840,6 +3841,9 @@ static void help(int exitcode)
            "-sd file        use 'file' as SecureDigital card image\n"
            "-pflash file    use 'file' as a parallel flash image\n"
            "-boot [a|c|d|n] boot on floppy (a), hard disk (c), CD-ROM (d), or network (n)\n"
+#ifdef TARGET_I386
+           "-bootmenu       BIOS will display boot menu when pressing F12\n"
+#endif
            "-snapshot       write to temporary files instead of disk image files\n"
 #ifdef CONFIG_SDL
            "-no-frame       open SDL window without a frame and window decorations\n"

@@ -4018,6 +4022,7 @@ enum {
     QEMU_OPTION_boot,
     QEMU_OPTION_snapshot,
 #ifdef TARGET_I386
+    QEMU_OPTION_bootmenu,
     QEMU_OPTION_no_fd_bootchk,
 #endif
     QEMU_OPTION_m,

@@ -4114,6 +4119,7 @@ static const QEMUOption qemu_options[] = {
     { "boot", HAS_ARG, QEMU_OPTION_boot },
     { "snapshot", 0, QEMU_OPTION_snapshot },
 #ifdef TARGET_I386
+    { "bootmenu", 0, QEMU_OPTION_bootmenu },
     { "no-fd-bootchk", 0, QEMU_OPTION_no_fd_bootchk },
 #endif
     { "m", HAS_ARG, QEMU_OPTION_m },

@@ -4772,6 +4778,9 @@ int main(int argc, char **argv, char **envp)
                 drive_add(optarg, FD_ALIAS, popt->index - QEMU_OPTION_fda);
                 break;
 #ifdef TARGET_I386
+            case QEMU_OPTION_bootmenu:
+                bootmenu = 1;
+                break;
             case QEMU_OPTION_no_fd_bootchk:
                 fd_bootchk = 0;
                 break;

Gleb Natapov

2008-12-18 13:30 UTC #1 lore raw

Quoted 15 lines · Jan Kiszka

pc-bios/bios-pq/0006_optional-boot-menu.patch new file +9 -0

new file mode 100644
index 0000000..bbe5753
@@ -0,0 +1,19 @@
+Make interactive boot menu optional.
+
+Signed-off-by: Jan Kiszka <[email protected]>
+
+diff --git a/bios/rombios.c b/bios/rombios.c
+index 123672f..7ce5b6c 100644
+--- a/bios/rombios.c
++++ b/bios/rombios.c
+@@ -2026,6 +2026,10 @@ interactive_bootkey()

pc-bios/bios-pq/0006_optional-boot-menu.patch line 19

Quoted 10 lines

pc-bios/bios-pq/0006_optional-boot-menu.patch new file +10 -0

+   Bit16u ss = get_SS();
+   Bit16u valid_choice = 0;
+ 
++  /* QEMU sets CMOS byte 0x60 to non-zero if the boot menu should be skipped */
++  if (inb_cmos(0x60))
++    return;
++
+   while (check_for_keystroke())
+     get_keystroke();
+

Why not push this upstream?

--
Gleb.

Jan Kiszka

author

2008-12-18 16:06 UTC #2 lore raw

Quoted 19 lines · Gleb Natapov

Quoted 18 lines · Jan Kiszka

pc-bios/bios-pq/0006_optional-boot-menu.patch new file +12 -0

new file mode 100644
index 0000000..bbe5753
@@ -0,0 +1,19 @@
+Make interactive boot menu optional.
+
+Signed-off-by: Jan Kiszka <[email protected]>
+
+diff --git a/bios/rombios.c b/bios/rombios.c
+index 123672f..7ce5b6c 100644
+--- a/bios/rombios.c
++++ b/bios/rombios.c
+@@ -2026,6 +2026,10 @@ interactive_bootkey()
+   Bit16u ss = get_SS();
+   Bit16u valid_choice = 0;
+

Quoted 8 lines

pc-bios/bios-pq/0006_optional-boot-menu.patch line 19
Quoted 7 lines
pc-bios/bios-pq/0006_optional-boot-menu.patch new file +7 -0
++  /* QEMU sets CMOS byte 0x60 to non-zero if the boot menu should be skipped */
++  if (inb_cmos(0x60))
++    return;
++
+   while (check_for_keystroke())
+     get_keystroke();
+ 
Why not push this upstream?

I wanted to wait at least for some comments here first, then push this to bochs.

Jan

Signature · 2 lines

Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

Paul Brook

2008-12-18 16:20 UTC #3 lore raw

In reply to Jan Kiszka

Quoted 11 lines · Jan Kiszka

When booting a guest from the command line, you normally do not need the interactive boot menu with its 3 s waiting that someone might press F12. So this patch introduces a mechanism to enable the boot menu only on demand, ie. when the user provided the command line switch -bootmenu. This reduces boot times to their original dimension.
The host-guest interface used here is CMOS RAM byte 0x60. If it is non-zero, the guest BIOS will skip the F12 delay, keeping the previous behavior in case the host does not support it. -bootmenu was chosen in favor of -boot as the syntax of the latter is not easily and cleanly extensible.

I'm not sure I believe this. We already support multiple options to -boot so why not just add another one (e.g. "q") that means include the boot menu? i.e. -boot qcad would give the current behaviour.

I've no particular preference whether this is communicated to the bios via the current 0x3d region or via a new byte. It looks like there's a spare bit in byte 0x38 that could be used.

Paul

Anthony Liguori

2008-12-18 16:29 UTC #4 lore raw

Quoted 15 lines · Paul Brook

Quoted 6 lines · Jan Kiszka
When booting a guest from the command line, you normally do not need the interactive boot menu with its 3 s waiting that someone might press F12. So this patch introduces a mechanism to enable the boot menu only on demand, ie. when the user provided the command line switch -bootmenu. This reduces boot times to their original dimension.
Quoted 6 lines
The host-guest interface used here is CMOS RAM byte 0x60. If it is non-zero, the guest BIOS will skip the F12 delay, keeping the previous behavior in case the host does not support it. -bootmenu was chosen in favor of -boot as the syntax of the latter is not easily and cleanly extensible.

Quoted 3 lines

I'm not sure I believe this. We already support multiple options to -boot so why not just add another one (e.g. "q") that means include the boot menu? i.e. -boot qcad would give the current behaviour.

Or -boot cad,prompt=[on|off]

Quoted 2 lines

I've no particular preference whether this is communicated to the bios via the current 0x3d region or via a new byte. It looks like there's a spare bit in byte 0x38 that could be used.

Or firmware config since that can be shared with non-x86 targets.

Regards,

Anthony Liguori

Quoted 4 lines

Paul

Jan Kiszka

author

2008-12-18 16:57 UTC #5 lore raw

Quoted 16 lines · Anthony Liguori

Quoted 15 lines · Paul Brook
Quoted 12 lines · Jan Kiszka
When booting a guest from the command line, you normally do not need the interactive boot menu with its 3 s waiting that someone might press F12. So this patch introduces a mechanism to enable the boot menu only on demand, ie. when the user provided the command line switch -bootmenu. This reduces boot times to their original dimension.
The host-guest interface used here is CMOS RAM byte 0x60. If it is non-zero, the guest BIOS will skip the F12 delay, keeping the previous behavior in case the host does not support it. -bootmenu was chosen in favor of -boot as the syntax of the latter is not easily and cleanly extensible.

Quoted 7 lines

Quoted 5 lines
I'm not sure I believe this. We already support multiple options to -boot so why not just add another one (e.g. "q") that means include the boot menu?
i.e. -boot qcad would give the current behaviour.
Or -boot cad,prompt=[on|off]

-boot currently takes arbitrary characters from a-z. Adding some extension means changing a lot of code (the users are unfortunately not well structured right now). And how to deal with the monitor interface then? Keep it, extend it? Moreover, how should we express the case of enabling the boot menu without providing any boot device, "-boot prompt=on"? Then parsing this will be fun - not impossible, for sure. But so far I'm looking for a straightforward approach.

Quoted 5 lines

Quoted 5 lines
I've no particular preference whether this is communicated to the bios via the current 0x3d region or via a new byte. It looks like there's a spare bit in byte 0x38 that could be used.

There are even more bits left in this byte. If CMOS is the final way to go, I will switch to this.

Quoted 2 lines

Or firmware config since that can be shared with non-x86 targets.

I'm open for the firmware config if you explain to me how state information is supposed to be transfered from rombios32.c (where the fw_cfg is evaluated) to some function in rombios.c. Tried this but found nothing obvious.

Jan

Signature · 2 lines

Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

Anthony Liguori

2008-12-18 17:23 UTC #6 lore raw

Quoted 11 lines · Jan Kiszka

Quoted 5 lines · Anthony Liguori
Quoted 1 line · Paul Brook
Or -boot cad,prompt=[on|off]
-boot currently takes arbitrary characters from a-z. Adding some extension means changing a lot of code (the users are unfortunately not well structured right now).

Our user interface should not be dictated by our lack of structure internally. That said, I don't believe it's as bad as you may first think.

If you parse the parameters of the string in vl.c, you can construct a new string that just contains "cad" and pass that to machine_init. That makes it pretty straight forward.

Quoted 2 lines

And how to deal with the monitor interface
then? Keep it, extend it?

Extend it with the same syntax, in the same fashion.

Quoted 5 lines

Moreover, how should we express the case of
enabling the boot menu without providing any boot device, "-boot prompt=on"? Then parsing this will be fun - not impossible, for sure. But so far I'm looking for a straightforward approach.

I don't know that that syntax is needed. You could force -boot ,prompt=on but I think just explicitly specifying -boot cad,prompt=on is enough.

Quoted 8 lines

Quoted 2 lines
Or firmware config since that can be shared with non-x86 targets.
I'm open for the firmware config if you explain to me how state information is supposed to be transfered from rombios32.c (where the fw_cfg is evaluated) to some function in rombios.c. Tried this but found nothing obvious.

Gleb, could you comment here? I'm obviously ignorant of the firmware config code in the BIOS. It seems like the right thing to use but if it's all the current support is in 32-bit code, it may be difficult to use that within the 16-bit code without rewriting it all.

Regards,

Anthony Liguori

Quoted 2 lines

Jan

Gleb Natapov

2008-12-18 17:41 UTC #7 lore raw

Quoted 11 lines · Anthony Liguori

Quoted 5 lines
I'm open for the firmware config if you explain to me how state information is supposed to be transfered from rombios32.c (where the fw_cfg is evaluated) to some function in rombios.c. Tried this but found nothing obvious.
Gleb, could you comment here? I'm obviously ignorant of the firmware config code in the BIOS. It seems like the right thing to use but if it's all the current support is in 32-bit code, it may be difficult to use that within the 16-bit code without rewriting it all.

Firmware config is accessed by inb/outw IO instructions so it should be easy to do that from rombios.c. But it is possible to read the option in rombios32.c and put it somewhere in unused space in 0x400 and check the value from rombios.c.

--
Gleb.

Laurent Vivier

2008-12-18 18:44 UTC #8 lore raw

Quoted 12 lines · Gleb Natapov

Quoted 11 lines · Anthony Liguori
Quoted 5 lines
I'm open for the firmware config if you explain to me how state information is supposed to be transfered from rombios32.c (where the fw_cfg is evaluated) to some function in rombios.c. Tried this but found nothing obvious.
Gleb, could you comment here? I'm obviously ignorant of the firmware config code in the BIOS. It seems like the right thing to use but if it's all the current support is in 32-bit code, it may be difficult to use that within the 16-bit code without rewriting it all.

Quoted 4 lines

Firmware config is accessed by inb/outw IO instructions so it should be easy to do that from rombios.c. But it is possible to read the option in rombios32.c and put it somewhere in unused space in 0x400 and check the value from rombios.c.

Look at my patches to add splash screen: they use firmware configuration device from rombios.c.

Regards,
Laurent
----------------------- Laurent Vivier ---------------------- "The best way to predict the future is to invent it."
- Alan Kay

Jan Kiszka

2008-12-18 21:29 UTC #9 lore raw

Quoted 16 lines · Laurent Vivier

Quoted 13 lines · Gleb Natapov
Quoted 12 lines · Anthony Liguori
Quoted 6 lines
I'm open for the firmware config if you explain to me how state information is supposed to be transfered from rombios32.c (where the fw_cfg is evaluated) to some function in rombios.c. Tried this but found
nothing obvious.
Gleb, could you comment here? I'm obviously ignorant of the firmware config code in the BIOS. It seems like the right thing to use but if it's all the current support is in 32-bit code, it may be difficult to use that within the 16-bit code without rewriting it all.

Quoted 8 lines

Quoted 4 lines
Firmware config is accessed by inb/outw IO instructions so it should be easy to do that from rombios.c. But it is possible to read the option in rombios32.c and put it somewhere in unused space in 0x400 and check the value from rombios.c.
Look at my patches to add splash screen: they use firmware configuration device from rombios.c.

If replicating qemu_cfg_port_probe & friends is OK, we should at least agree on using common helpers within those two bios domains.

Jan

Anthony Liguori

2008-12-18 16:27 UTC #10 lore raw

In reply to Jan Kiszka

Quoted 14 lines

pc-bios/bios-pq/0006_optional-boot-menu.patch new file +6 -0

new file mode 100644
index 0000000..bbe5753
@@ -0,0 +1,19 @@
+Make interactive boot menu optional.
+
+Signed-off-by: Jan Kiszka <[email protected]>
+
+diff --git a/bios/rombios.c b/bios/rombios.c
+index 123672f..7ce5b6c 100644

pc-bios/bios-pq/0006_optional-boot-menu.patch line 16

Quoted 10 lines

pc-bios/bios-pq/0006_optional-boot-menu.patch new file +10 -0

+--- a/bios/rombios.c
++++ b/bios/rombios.c
+@@ -2026,6 +2026,10 @@ interactive_bootkey()
+   Bit16u ss = get_SS();
+   Bit16u valid_choice = 0;
+ 
++  /* QEMU sets CMOS byte 0x60 to non-zero if the boot menu should be skipped */
++  if (inb_cmos(0x60))
++    return;
++

Should we be using firmware config for this?

I think I'd still like to see BIOS patches submitted as separate patches. We'll take care of updating the series file and sticking them into the right place. Diffs of diffs are pretty hard for me to read :-)

Regards,

Anthony Liguori