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.
This isn't supported by an option ROM; there *is* no BCV/BEV address. Like IDE, it's a device which is natively supported by the CSM BIOS. So the BBS_TABLE specifies the PCI bus/device/function of the virtio PCI device that qemu exposes to the guest, and that is sufficient for the CSM to match it up and place it in the correct place in the boot order. This is the one use case for which the existing BBS_TABLE *does* seem to work correctly. Even for IDE it's broken, because there's no sane way to tell which entry in the BBS_TABLE is for the primary/secondary master/slave devices. Currently we have this horrid hack where we infer it from the *position* in the BBS_TABLE[] array! And that's completely broken when we get to things like SCSI or SATA controllers which are again supported natively by the BIOS, and can have large numbers of drives attached. We *can't* use fixed positions in the BBS_TABLE array for that. We need to add some kind of 'lun' field to the BBS_TABLE structure. It occurs to me that maybe we're approaching this from the wrong angle, and that maybe we should be adding these entries to the BBS_TABLE from the CSM's Legacy16UpdateBbs function? But there's no way we can do that safely because we're not allowed to touch the *hardware* there, so we can't know what devices are attached. Hell, OVMF doesn't even execute boot ROMs on PCI devices that it doesn't have a native driver for (apart from the VGA) so even *those* don't turn up in the UEFI boot menu. Although the PXE ROM on the network card *will* get invoked just before *actually* booting, much too late for the user to *choose* it... This whole thing seems to be quite broken, unless I'm seriously misunderstanding it. I suspect that what people are *actually* shipping bears little relation to what's in EDK-II :( -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
