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
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
