On 08/28/13 13:53, Michael Chang wrote: > Do you have any suggestions on why it cannot be reproduce on my side ? > Finally provide my virt-install options for reference. > > virt-install --connect qemu:///system --name vmos123efi > --virt-type=kvm --os-type=linux --os-variant=opensuse12 --disk > path=/dev/system/vmos123efi --network bridge=br0,model=virtio > --cdrom=/home/linux/Downloads/openSUSE-12.3-DVD-x86_64.iso --vcpus=4 > --ram 1024 --boot loader=/home/linux/OVMF/OVMF-f1f4721.fd
Hm. This seems to suggest that edk2 can actually boot a non-root-anchored (ie. relative) device path such as HD(1,800,4e000,87f09d6f-dc40-4eaf-b90b-9c2c7d4ffdb5)File(\EFI\opensuse\grubx64.efi) and that the difference between the symptoms we're seeing could be rooted in the boot order handling ("OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c"). SetBootOrderFromQemu() implements the following nested loop: for each entry OFW in the fw_cfg boot order list: translate the OpenFirmware device path OFW to the UEFI device path DP_PREFIX for each entry BOOT in the UEFI boot option list if DP_PREFIX is a prefix of BOOT: append BOOT to the new boot order replace the current boot order with the new boot order Basically, it loads the boot order specification from qemu, from the "bootorder" fw_cfg file. That file contains device paths in OpenFirmware format. Each entry there is converted to a UEFI device path prefix, and looked up in the UEFI boot option list. If there's a match, the matching UEFI boot option is appended to the new boot order. This filters the UEFI boot option list to those that the user requested via fw_cfg, reorders them, and kills off the (non-requested) rest. UEFI boot options of the form HD(1,800,4e000,87f09d6f-dc40-4eaf-b90b-9c2c7d4ffdb5)File(\EFI\opensuse\grubx64.efi) don't match *any* output from the OFW->UEFI device path translation, hence they are always removed. I assumed that would be no problem, since such (root-less, ie. relative) device paths should be unbootable anyway. Apparently edk2 can boot them nonetheless? Note that when you configure a boot option in the OVMF TUI, that is also an absolute device path. ( For example, consider the following boot order set in virt-manager: (1) Hard Disk (2) CDROM (3) Network (PXE) In the domain XML this corresponds to <domain type='kvm'> ... <os> ... <boot dev='hd'/> <boot dev='cdrom'/> <boot dev='network'/> </os> ... </domain> Which libvirt in turn translates to the following qemu command line options: -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=5,lun=6,drive=drive-scsi0-0-5-6,id=scsi0-0-5-6,bootindex=1 ^^^^^^^^^^^ -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 ^^^^^^^^^^^ -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:57:e2:b3,bus=pci.0,addr=0x3,bootindex=3 ^^^^^^^^^^^ Which in turn :) translates to the following contents in the "bootorder" fw_cfg file: /pci@i0cf8/scsi@4/channel@0/disk@5,6 /pci@i0cf8/ide@1,1/drive@1/disk@0 /pci@i0cf8/ethernet@3/ethernet-phy@0 As a result, SetBootOrderFromQemu() does the following: SetBootOrderFromQemu: FwCfg: /pci@i0cf8/scsi@4/channel@0/disk@5,6 /pci@i0cf8/ide@1,1/drive@1/disk@0 /pci@i0cf8/ethernet@3/ethernet-phy@0 SetBootOrderFromQemu: FwCfg: <end> Here the fw_cfg contents is dumped. ParseOfwNode: DriverName="pci" UnitAddress="i0cf8" DeviceArguments="" ParseOfwNode: DriverName="scsi" UnitAddress="4" DeviceArguments="" ParseOfwNode: DriverName="channel" UnitAddress="0" DeviceArguments="" ParseOfwNode: DriverName="disk" UnitAddress="5,6" DeviceArguments="" TranslateOfwPath: success: "PciRoot(0x0)/Pci(0x4,0x0)/Scsi(0x5,0x6)" First entry (virtio-scsi disk, "/pci@i0cf8/scsi@4/channel@0/disk@5,6") has been translated from OFW to UEFI. No we enter the inner loop. Match: against "PciRoot(0x0)/Pci(0x4,0x0)/Scsi(0x5,0x6)/HD(1,GPT,87B09CBE-32B9-4737-8ECC-C1E65702CFB6,0x800,0x64000)/\EFI\redhat\grub.efi": match A match was immediately found; this is placed as first boot option into BootOrder. We return to the outer loop. ParseOfwNode: DriverName="pci" UnitAddress="i0cf8" DeviceArguments="" ParseOfwNode: DriverName="ide" UnitAddress="1,1" DeviceArguments="" ParseOfwNode: DriverName="drive" UnitAddress="1" DeviceArguments="" ParseOfwNode: DriverName="disk" UnitAddress="0" DeviceArguments="" TranslateOfwPath: success: "PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0)" Second OFW entry (IDE CD-ROM, "/pci@i0cf8/ide@1,1/drive@1/disk@0") has been translated, we enter the inner loop. Match: against "PciRoot(0x0)/Pci(0x4,0x0)/Scsi(0x5,0x6)/HD(1,GPT,87B09CBE-32B9-4737-8ECC-C1E65702CFB6,0x800,0x64000)/\EFI\redhat\grub.efi": no match Match: against "PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0)": match We found a match for this one too, it is going to be placed second in BootOrder. ParseOfwNode: DriverName="pci" UnitAddress="i0cf8" DeviceArguments="" ParseOfwNode: DriverName="ethernet" UnitAddress="3" DeviceArguments="" ParseOfwNode: DriverName="ethernet-phy" UnitAddress="0" DeviceArguments="" TranslateOfwPath: success: "PciRoot(0x0)/Pci(0x3,0x0)/MAC" Match: against "PciRoot(0x0)/Pci(0x4,0x0)/Scsi(0x5,0x6)/HD(1,GPT,87B09CBE-32B9-4737-8ECC-C1E65702CFB6,0x800,0x64000)/\EFI\redhat\grub.efi": no match Match: against "PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0)": no match Match: against "PciRoot(0x0)/Pci(0x3,0x0)/MAC(52540057E2B3,0x1)": match Third OFW entry (virtio-net NIC, "/pci@i0cf8/ethernet@3/ethernet-phy@0") translated and found, and to be appended third to the BootOrder variable. TranslateOfwPath: no more nodes We're done with the "bootorder" fw_cfg file. EmuVariablesUpdatedCallback Saved NV Variables to NvVars file SetBootOrderFromQemu: setting BootOrder: success We've successfully rewritten the BootOrder NvVar. ) Your virt-install command makes me think that no "bootorder" fw_cfg file is being presented in your case. Under that circumstance SetBootOrderFromQemu() doesn't touch the BootOrder UEFI variable -- potentially allowing the relative HD(...)File(\EFI\opensuse\grubx64.efi) devpath to reach later parts of edk2 that can in fact boot it. ... Can you please rebuild your OVMF with DEBUG_VERBOSE enabled (ie. bit-or 0x00400000 in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", in OvmfPkgX64.dsc), and post the debug output? Thanks Laszlo ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel