On 08/16/14 01:56, Reza Jelveh wrote:
> On 15/08/14 12:50, Laszlo Ersek wrote:
>> Sure.
>>
>> First, by looking at (and maybe posting) the debug log section that I
>> described before.
>>
>> Second, by creating a virtual machine as follows:
>> - ATA disk in IDE or AHCI mode, with booindex spec
>> - ATA CD-ROM in IDE or AHCI mode, with bootindex spec
>> - virtio-net NIC, with bootindex spec, and also add ",romfile=" to
>> stick with OVMF's builtin virtio-net driver for now, not the external
>> oprom from the iPXE project
>>
>> (The above describes 2x2x1 == 4 hardware configurations, where each
>> hardware configuration allows 3! = 6 full boot order possibilities; in
>> total: 4 * 6 == 24 command lines.)
>>
>> The ISO image connected to the CD-ROM should contain a Linux installer
>> or LiveCD (eg. Fedora).
>>
>> The virtual disk image (== the drive) under the ATA disk should contain
>> an installed UEFI OS (eg. the same Fedora version that you have on the
>> LiveCD).
>>
>> For the virtio-net NIC, you should set up a local PXE boot server. You
>> can use qemu's builtin server (with -netdev user), or you can use
>> dnsmasq. The PXE payload offered by the server should be a UEFI
>> application -- it's easiest to pick the *old* EFI shell binary, from
>> "EdkShellBinPkg/FullShell/X64/Shell_Full.efi".
>>
>> Then:
>>
>> for each hw config in 0 .. 2*2*1:
>> for each boot order in 0 .. 3*2*1:
>> boot it
>>
>> That is, for each hardware configuration out of the four possible, go
>> through all six possible boot orders, and see if reality matches the
>> expectations. You can verify how each works, looking at the debug log,
>> and also (obviously) the bootindex=0 option should always boot. (You can
>> distinguish the installed OS from the LiveCD from the old EFI shell.)
>>
>> (It's probably best to test this out first without applying your patch,
>> ie. one hw config, where you have a traditional IDE disk and a
>> traditional IDE cd-rom, and you just test the 6 boot orders.)
>
> This seems overkill doesn't it?
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.
Getting the boot order heuristics right in OVMF was a long and painful
process. I wouldn't be amused by regressions. In particular OVMF should
cooperate with libvirt as well as possible (where you can change the
boot order within the same hw config with two clicks in virt-manager).
If you can reduce the 24 test cases to a smaller set with the same
coverage, go ahead.
> I'm using the following instead
> BOOT=fat:$PREFIX/run-ovmf/hda-contents2
>
> -cdrom ${ISO} -hda ${BOOT} -hdb ${PREFIX}/mac_hdd_raw.img
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.
Qemu's command line hasn't been, for ages, an end-user interface. (And
-readconfig is not a substitute, because it doesn't do any of the
option-specific *extra* logic; it just reads some QemuOpts, which is not
a full replacement.) Qemu's command line is an API.
> anyway,
>
> it looks like the pci device paths are the same, but not all filesystems are
> detected
OVMF supports FAT (more precisely, EFI System Partitions). There's no
reason to expect other filesystem types to work (unless you have a
custom build with a non-upstream filesystem driver).
(... or maybe you meant "FAT instances" rather than "filesystem types")
> which leads me to believe that ide mode is either not correctly
> initialized or there is another another channelcount error
>
Thanks for checking.
Laszlo
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
