On 02/08/13 09:00, David Woodhouse wrote:
On Fri, 2013-02-08 at 04:44 +0000, Li, Elvin wrote:
I guess this virtual disk comes from a virtual diskcontroller. Now you only fill an entry in BBS table to show legacy boot options, I am unclear that how you enable real legacy boot for this virtual disk finally? The bbs entry you filled does not include the BCV/BEV address and is more like a dummy entry.
Which is exactly like the entries for IDE devices. If you care, take a look at the way it's handled in the SeaBIOS CSM, with csm_bootprio_pci() funding the appropriate entry in the table and ordering the boot option accordingly.
[...]
I think we should squeeze device paths through the BbsTable. Either UEFI device paths or OpenFirmware device paths.
Seabios seems to work like this (with CONFIG_BOOT enabled -- which is disabled for the CSM build):
- the Bootorder array is filled with OpenFirmware device paths from fw_cfg,
- when device drivers (virtio-blk, virtio-scsi etc) initialize/add a device, they all need a boot priority for it, apparently. So they call a bootprio_find_XXXX_device() function, where XXXX corresponds to the specific device type ("pci" for virtio-blk, "scsi" for virtio-scsi and other scsi drivers).
- bootprio_find_XXXX_device() has XXXX-specific parameters. It formats an OpenFirmware device path, with wildcards, based on the incoming parameters (BDF for pci, +target +lun for scsi). Then the Bootorder array is searched with glob_prefix().
In short, each specific device brings itself to OpenFirmware "wildcard format", then the Bootorder array can be searched by common code.
IIUC, David has changed this code so that, in the CSM build, bootprio_find_XXXX_device() does not format an OpenFirmware glob, nor does it search the Bootorder array. (Actually, Bootorder is not initialized in the CSM build.) Instead, bootprio_find_XXXX_device() searches the BbsTable exported by the edk2 CSM code.
Unfortunately, the BbsTable record is not flexible enough to relay all information in a broken-out format. Currently the code can find:
- virtio-blk devices, because for those only the PCI BDF is needed, and those are passed in BbsTable[n].{Bus,Device,Function},
- floppy & ATA disks -- these take a fixed position (record offset) in the BbsTable.
For more flexibility, I think the following should be possible to implement:
- Allocate a thus far unreserved flag in BbsTable[n].StatusFlags (and/or use BBS_BEV_DEVICE in BbsTable[n].DeviceType),
- when it is set, guarantee that the DescString is a textual UEFI device path (which doesn't hurt when "naively" displayed either), and set the usual broken-out fields to invalid/nonexistent devices,
- in edk2's LegacyBiosBuildBbs(), enumerate all handles with EFI_BLOCK_IO_PROTOCOL, and tack their textual devpaths after the existing 5 entries to the BbsTable, as BBS_UNPRIORITIZED_ENTRY,
- in the CSM build of seabios, bootprio_find_XXXX_device() should format an UEFI device path fragment, and search csm_boot_table->BbsTable[*].DescString for it (filtered for records that have the special flag).
This would eliminate yet another OFW<->UEFI devpath conversion, hopefully be flexible enough for SeaBIOS, and shouldn't confuse non-SeaBIOS CSMs. (We can of course make the entire functionality dependent on a new IntelFrameworkModulePkg PCD whose value we override in OvmfPkg.)
... BTW why can't SeaBIOS grab the bootorder fw_cfg file just the same in the CSM build? (Commit 60258aa4 in David's repo.)
Thanks Laszlo