[SeaBIOS] [edk2] [PATCH 2/2] LegacyBbs: add boot entries for virtio-blk devices

[Laszlo Ersek]

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 disk
>> controller. 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