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

Reply via email to