On Thu, Apr 08, 2021 at 01:32:47PM +0200, Gerd Hoffmann wrote:
I changed the number of namespaces my controller reports to 1 and it worked fine. Is there an easy way to get around this or do I have to fix the code? I haven't looked at the code in detail, but I think we don't have to allocate the array of namespaces in nvme_controller_enable; instead, we can probe a namespace right before we attempt to boot from it (not sure where exactly this is done).
Well, you can try skip non-bootable namespaces and use "qemu -boot strict=on". It happens on nvme controller level already (see nvme_controller_setup()).
AFAIK this applies to the entire controller, not individual namespaces.
Current code, yes, but you can change the driver to do the same on namespace level (simliar to how virtio-scsi skips non-bootable disks) ...
Easy way out without actual code changes would be to use two nvme controllers, one for the boot disk, one for all others, set bootindex for the boot disk only (and use strict=on of course). seabios should completely ignore the second nvme controller then.
That's not option for me as this will be a customer VM so we don't know on which NS the OS will be installed.
... except that it doesn't help much if you don't know which NS the OS is installed on.
In another email I said that increasing BUILD_MIN_BIOSTABLE by 8x solves the problem, is there a problem with this solution?
redhat increases BUILD_MIN_BIOSTABLE too (4x only though).
I think this was discussed before but google doesn't find me anything so not sure why BUILD_MIN_BIOSTABLE hasn't been increased upstream. Maybe it doesn't work with some configurations due to running out of address space. Should that be the case a config option could be a way out.
I don't recall discussing BUILD_MIN_BIOSTABLE and there isn't history of it on the mailing list.
I get the following on the current build:
Fixed space: 0xe05b-0x10000 total: 8101 slack: 10 Percent slack: 0.1% 16bit size: 38048 32bit segmented size: 2292 32bit flat size: 46540 32bit flat init size: 84576 Lowmem size: 2240 f-segment var size: 1248 ... Total size: 181248 Fixed: 88128 Free: 80896 (used 69.1% of 256KiB rom)
The main constraint is that the "16bit", "32bit segmented", "f-segment var", and biostable sections must fit in the f-segment (~42K today). The secondary constraint is on option rom space - the above plus "32bit flat", "lowmem", any dynamic low memory allocations, and option roms must all fit in 256KiB (starting at ~90K today). The third constraint is that the image as a whole (including biostable space) must fit in 256KiB (~181K today). Finally, there is the "corner case" where if someone does not select RELOCATE_INIT, then everything (including dynamic memory and option roms) must fit in 256KiB.
So, it does seem like we have space available to increase BUILD_MIN_BIOSTABLE. The challenge is mostly on managing risks wrt to other failure cases.
Is QEMU still shipping images limited to 128KiB? If so, that would be another restriction.
-Kevin