On 01/22/13 03:59, Andrew Fish wrote: > > On Jan 21, 2013, at 5:40 PM, David Woodhouse <dw...@infradead.org> wrote: > >> On Mon, 2013-01-21 at 16:59 -0800, Andrew Fish wrote: >>> Not sure if BdsGetBootTypeFromDevicePath() is broken, or functioning >>> as intended. Remember in EFI there is not a concept of a bootable >>> non-removable block IO device.
Ah, that explains the intent. >>> The OS installs the OS loader as a >>> file and updates a variable to contain the path to the OS loader. This >>> allows an arbitrary number of operating systems to boot from a single >>> disk. OK, this is where the problem is introduced. When one installs the OS of choice with the OS's UEFI installer, at some point the installer will update the BootOrder non-volatile variable. At this point the installer has of course already called the gBS->ExitBootServices() boot service, so only runtime services are available to it (one of which is gRT->SetVariable(), so trying to update the BootOrder variable itself is fine). Non-volatile variables would be stored in flash (nvram) on a physical platform. qemu (without KVM) supports flash emulation. qemu (with KVM) doesn't -- AFAIK it would take a type of memory that reads as ROM/RAM but writes as MMIO, see "memory.c" in qemu-kvm --, so OVMF works it around: - before gBS->ExitBootServices() is called, non-volatile variables are stored on the (virtual) disk, in the \NvVars file on the boot partition / vfat fs, - after gBS->ExitBootServices() has been called -- that is, when the installer would set up the boot option for the OS just installed onto the non-removable disk -- the resident set of OVMF cannot know if the same boot filesystem holding \NvVars is accessible to (mounted by) the OS, and therefore it skips the write (gRT->SetVariable() has no effect). Jordan had pointed out the file that implements this check; see PlatformFvbDataWritten() in "OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.c". (It doesn't do anything if EfiAtRuntime() returns "true".) >>> So if you add a "bootable" disk into a system you still have to >>> manually config the file that is the OS loader. Yes, this fallback works, as I attempted to describe in my previous email. Even SetBootOrderFromQemu() runs before ExitBootServices() is called, so the reordering it does gets actually stored in \NvVars. >>> >>> It is possible to add heuristics to know about well known loader >>> names, etc, but the open source code does not do any of this. >> >> Yes, absolutely. Except that as discussed on the mailing list in the >> not-so-distant past, it's very hard to tell what is "removable" and what >> isn't these days, > > EFI_BLOCK_IO_PROTOCOL *BlkIo; > > BlkIo->Media->RemovableMedia > > Keys the EFI behavior. Other than that it is up to the person writing the EFI > driver. Yes, this field is set to FALSE in VirtioBlkInit() [OvmfPkg/VirtioBlkDxe/VirtioBlk.c]; for many good reasons (it's even mentioned in the file's leading comment): - detaching/attaching a virtio-blk disk is maybe not the most critical functionality, - block io protocol exported for removable media has to implement a bunch of extra callbacks, - it would require OVMF to handle PCI hotplug/hot-unplug (people would attemt to add/remove virtio-blk disks in virt-manager eg.), which would necessitate severe improvements in at least the ACPI stuff in OVMF. Too little bang for the buck. Laszlo ------------------------------------------------------------------------------ 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
