On Mon, 2013-01-21 at 18:59 -0800, Andrew Fish wrote: > EFI_BLOCK_IO_PROTOCOL *BlkIo; > > BlkIo->Media->RemovableMedia > > Keys the EFI behavior.
It does, slightly. EFI puts removable devices before non-removable ones
in the list. That's it, AFAICT.
It *isn't* relevant to the question of whether a device shows up in the
list or not.
> Other than that it is up to the person writing the EFI driver.
I would love to find that this is the case, and 'fix' the VirtioBlk
device to ensure that its disks do appear in the menu. I just don't see
how.
> > and currently there *is* a well-known loader name
> > of /etc/boot/boot${ARCHITECTURE}.efi which OVMF *will* attempt to boot.
> >
> Thought it was /EFI/BOOT/BOOT{arch}.EFI as the spec....
Sorry, yes. A typo.
> My point is the device path should not matter, and it seems to be used
> to mostly generate a string.
Are we looking at the same code base? Between the
BdsGetBootTypeFromDevicePath() and BdsLibEnumerateAllBootOption()
functions in IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c,
it definitely seems to be using the device path as the *only* criterion
for determining whether to list the given device as a boot option or
not.
> >
> > And we probably *don't* want to register every *partition*.
>
> Well if you use the removable media rules then you only need to show
> partitions with the magic file. If you are not using the removable
> media rules the user can pick.
>
> >
> >>> I expected to see it appear *twice* in my boot menu; once for EFI
> >>> booting and once for the CSM. But neither of them appear...
> >>
> >> I've not thought about legacy BIOS for a long time, but you boot from
> >> C: or A:. It is up to the BIOS to define what is A: or what is C: The
> >> BBS spec allows selection of what is C: but that is a CSM and not EFI
> >> thing. You should be able to add a BBS device path node for C: and let
> >> the CSM figure out what is C:.
> >
> > Except that in the CSM case, the "BIOS" isn't really in control; it's
> > supposed to do EFI's bidding. EFI passes the BBS_TABLE to the CSM which
> > controls the BCV priority. If the BBS_TABLE doesn't even *mention* the
> > virtio disk, then CSM doesn't know what priority it should have. To be
> > specific: the patch at
> > http://git.infradead.org/users/dwmw2/seabios.git/commitdiff/756273b1e8ed135a3178c5c2529c337471d460f5
> > would work fine on the CSM side for virtio disks, and would correctly
> > select which device is C: — if the EFI side actually gave me 'Legacy boot
> > from VirtIO disk' as an option in the menu and filled in the BBS_TABLE with
> > it correctly. Which it doesn't.
> >
> > I suspect that the LegacyBiosBuildBbs() function *also* needs to list
> > all the devices that produce the Block IO protocol, and add them all to
> > the table?
>
> So I'm confused don't you want to list PnP BCV devices? The PnP BIOS
> ROM should create an entry per LUN so it can be selected? This all has
> nothing to do with EFI or Bock IO.
The top-level view: When I boot a machine with a virtio block device, I
want it to behave like an IDE block device. I want the boot menu in EFI
to offer me *both* the option to boot from it as an EFI device
(using /EFI/BOOT/BOOT${ARCHITECTURE}.EFI), or to boot from it using the
CSM as a legacy BIOS boot. I currently get *neither*.
> > And we also need to add a LUN field to BBS_TABLE, ideally, because we
> > might have more than one device behind each PCI function, and we need to
> > distinguish between them. Could we use some of the reserved bits in
> > BBS_STATUS_FLAGS for that?
>
> Bad idea to use reserved bits.
I mean, of course, that a future version of the spec would no longer
call them 'reserved'.
> Again the PCI BIOS ROM should produce multiple BCV entries to let you
> pick the LUN.
But EFI hasn't even *invoked* the BIOS ROMs at the time the boot menu is
displayed to the user. It doesn't do that until it's actually decided to
do a legacy boot. The most interesting case is that of devices which
have EFI drivers, and for which we *assume* the CSM will have drivers
too; either natively or via option roms. Like the IDE. Which *does* kind
of work via BBS_TABLE, albeit only when the CSM makes horrid assumptions
and infers meaning from the *index* into the BBS_TABLE of each entry.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
