-----Original Message----- From: Gerd Hoffmann kraxel@redhat.com Sent: 16 April 2021 08:15 To: Thanos Makatos thanos.makatos@nutanix.com Cc: Kevin O'Connor kevin@koconnor.net; seabios@seabios.org; John Levon john.levon@nutanix.com; Swapnil Ingle swapnil.ingle@nutanix.com; Liu, Changpeng changpeng.liu@intel.com Subject: Re: [SeaBIOS] SeaBIOS fails to boot from NVMe controller with lots of namespaces
Hi,
Regarding the failure cases, will things break during build
(BUILD_MIN_BIOSTABLE=16K), e.g:
[seabios] Error! ROM doesn't fit (135584 > 131072) [seabios] You have to either increase the size (CONFIG_ROM_SIZE) [seabios] or turn off some features (such as hardware support not [seabios] needed) to make it fit. Trying a more recent gcc version [seabios] might work too. [seabios] make: *** [out/bios.bin.prep] Error 1
Or do we expect undefined behavior at run time?
Running out of memory can lead to undefined behavior at run time, depending on which allocations fail. Typical error pattern is that seabios can't initialize all devices, leading to boot failures.
256 namespaces is not an insanely huge number.
Well, back in the 80ies when the BIOS interfaces have been created 256 was an insanely huge number ...
Given we have a number of real mode constrains for compatibility reasons (like some data structures must live in the f segment) there is no easy way out, we simply can't support an unlimited number of disks (which btw is one of the reasons why the "skip non-bootable disks" code exists).
SeaBIOS only tries to boot from the first namespace; if that fails other namespaces aren't tried (https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/72LFLT7...). If we stick to the current behavior, then there's no reason to probe any other namespace apart from the first one. This greatly reduces memory requirements so we should be able to support the max number of namespaces.
Of course there is the option to leave behind the 80ies and go for UEFI.
Or can just live with it as you suggest and simply document it 😊.