On 08/21/14 11:44, Reza Jelveh wrote:
> Looks good to me, with another Ide patch it to fix slave devices I have
> attached the two logs. One with Idebus and IdeController and the other with
> AtaBus AtaAtapiPassthru and SataController.
I assume that you meant the following:
I ran the command line you provided, once pre-patch, once
post-patch, captured the outputs, and compared them. The following
section of the log file didn't change:
SetBootOrderFromQemu: FwCfg:
/pci@i0cf8/ide@1,1/drive@0/disk@0
/pci@i0cf8/ide@1,1/drive@1/disk@0
/pci@i0cf8/ethernet@4/ethernet-phy@0
SetBootOrderFromQemu: FwCfg: <end>
ParseOfwNode: DriverName="pci" UnitAddress="i0cf8" DeviceArguments=""
ParseOfwNode: DriverName="ide" UnitAddress="1,1" DeviceArguments=""
ParseOfwNode: DriverName="drive" UnitAddress="0" DeviceArguments=""
ParseOfwNode: DriverName="disk" UnitAddress="0" DeviceArguments=""
TranslateOfwPath: success:
"PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)"
Match: against "PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)": match
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)"
Match: against "PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)": no
match
Match: against "PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0)":
match
ParseOfwNode: DriverName="pci" UnitAddress="i0cf8" DeviceArguments=""
ParseOfwNode: DriverName="ethernet" UnitAddress="4" DeviceArguments=""
ParseOfwNode: DriverName="ethernet-phy" UnitAddress="0" DeviceArguments=""
TranslateOfwPath: success: "PciRoot(0x0)/Pci(0x4,0x0)"
Match: against "PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)": no
match
Match: against "PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0)": no
match
Match: against "PciRoot(0x0)/Pci(0x4,0x0)/MAC(525400123456,0x1)": match
TranslateOfwPath: no more nodes
BootOrderComplete: keeping
"MemoryMapped(0xB,0x900000,0x10FFFFF)/FvFile([Shell])"
BootOrderComplete: dropping "PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)"
BootOrderComplete: dropping "PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)"
SetBootOrderFromQemu: setting BootOrder: success
Thanks for testing this.
However it is only one boot order (out of the possible six) under one
hardware configuration (out of the possible four).
I'll allow that we can skip the five other boot orders under this same
hardware configuration, given that both the IDE HDD and the IDE CD-ROM
device paths remained stable, meaning both OpenFirmware and UEFI device
paths. Apparently your patches don't regress the IDE-only cases. Good.
But this result doesn't say anything about the device paths (OFW and
UEFI alike) that correspond to the AHCI mode hard disk, and to the AHCI
mode CD-ROM. (Ie. the test doesn't cover the three other hardware
configurations, where *at least* one of the hard disk and the CD-ROM is
in AHCI mode).
I did not offer any QEMU command lines to test those virtual hardware
configurations because I don't have the slightest clue how to set AHCI
on the QEMU command line. Please post an updated qemu command line
(based on the previous one) that flips at least one of the hdd & cdrom
to AHCI mode (and changes no other setting), and let's see how the boot
order code works then. (Of course this only makes sense with your
patches applied.)
If flipping between IDE and AHCI has no consequences for either OFW or
UEFI device paths, for either the hard disk or the CD-ROM, then your
patches are probably complete, as far as OvmfPkg is concerned. If AHCI
mode results in any differences in OFW or UEFI device paths, for either
the hard disk or the CD-ROM, then your patches are incomplete and the
devpath matching should be extended.
Thanks,
Laszlo
>
>
> On 17/08/14 01:32, Laszlo Ersek wrote:
>> On 08/16/14 20:34, Reza Jelveh wrote:
>>> On 16/08/14 14:51, Laszlo Ersek wrote:
>>>> You asked me how, in my opinion, you should test the new device paths. I
>>>> gave you an exhaustive test plan, the way I would test for regressions
>>>> and expected behavior. You can write a shell script with two loops, and
>>>> watch 24 boots. (You don't need to boot to the full OSes, the UEFI boot
>>>> loaders (grub etc) suffice to see which one got booted.) It can be done
>>>> in an hour or two, probably.
>>>>
>>>> ...
>>>>
>>>> In general I refuse shorthand flags like -cdrom, -hda, -boot etc.
>>>> Explicit -drive, -netdev and -device flags, and ,bootindex= properties
>>>> for -device, provide better control, and are more explicit about what
>>>> one should expect. It's not a coincidence libvirt spells out all options
>>>> with maximum accuracy.
>>> What is your preferred commandline for testing then?
>>
>> #!/bin/bash
>>
>> set -e -u -C
>>
>> # set boot order between HD, CD, and PXE
>> HD_IDX=0
>> CD_IDX=1
>> NET_IDX=2
>>
>> # some config stuff
>> ISO=Fedora-Live-Xfce-x86_64-20-1.iso
>> IMG=mytest.img
>> LOG=ovmf.log
>> TFTPDIR=$WORKSPACE/EdkShellBinPkg/FullShell/X64
>> BOOTFILE=/Shell_Full.efi
>> OVMF_CODE=$WORKSPACE/Build/OvmfX64/DEBUG_GCC48/FV/OVMF_CODE.fd
>> OVMF_VARS=$WORKSPACE/Build/OvmfX64/DEBUG_GCC48/FV/OVMF_VARS.fd
>>
>> if [ ! -e $IMG ]; then
>> qemu-img create -f qcow2 $IMG 20G
>> fi
>> if [ ! -e myvars.fd ]; then
>> cp $OVMF_VARS myvars.fd
>> fi
>>
>> /opt/qemu-installed/bin/qemu-system-x86_64 \
>> -M pc \
>> -enable-kvm \
>> -m 2048 \
>> -smp 2 \
>> -drive if=pflash,format=raw,readonly,file=$OVMF_CODE \
>> -drive if=pflash,format=raw,file=myvars.fd \
>> -global isa-debugcon.iobase=0x402 \
>> -debugcon file:$LOG \
>> -monitor stdio \
>> -device piix3-usb-uhci \
>> -device usb-tablet \
>> -drive id=drive0,if=none,format=qcow2,file=$IMG \
>> -device ide-hd,bus=ide.0,drive=drive0,bootindex=$HD_IDX \
>> -drive id=drive1,if=none,format=raw,readonly=on,file=$ISO \
>> -device ide-cd,bus=ide.1,drive=drive1,bootindex=$CD_IDX \
>> -netdev user,id=net0,tftp=$TFTPDIR,bootfile=$BOOTFILE \
>> -device virtio-net-pci,netdev=net0,romfile=,bootindex=$NET_IDX
>>
>>
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
