On 01/16/15 18:55, Bill Paul wrote: > Note: I'm not claiming this different behavior started specifically with > QEMU 2.2.0. Maybe it started somewhere earlier, but I haven't tried them > all to check. > > So, let me ask again: why is it that when I try to PXE boot with the > efi-e1000.rom in QEMU 2.2.0, I a) see the iPXE banner where I didn't > used to before, and more importantly b) PxeBaseCodeProtocol seems to be > busted? > > I was under the impression that with UEFI, the UEFI portion of a > combined option ROM would just be an UEFI driver for the NIC, i.e. that > provides SimpleNetworkProtocol, and all the other things like PXE and > the network stack were actually part of the UEFI firmware itself and > were layered on top of that. But here it seems like we're just getting > an instance of iPXE running instead.
iPXE can do that for (... "to") you. > I didn't think that was either > desired or possible. Desired, indeeed no (NB here our opinion differs from the iPXE author(s)'...), possible: yes. (Anything's possible when you can execute arbitrary code.) > (Legacy BIOS PXE ROMs are self-contained like this > because legacy BIOSes don't include any networking support of their own. > I thought UEFI provided all the network facilities itself and needs only > a driver for the underlying interface.) Yes. The answer to your question (which I hope I understand now) can be seen with this command, in the qemu.git tree: $ git log --oneline --reverse v1.7.0..v2.2.0 -- pc-bios/efi-e1000.rom d880b28 ipxe: update to current git That update picked up a great many iPXE changes: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d880b28 (See the BANNER_TIMEOUT / ROM_BANNER_TIMEOUT changes at the end.) ... I *think* you can build iPXE not to "hijack" the boot process via its UEFI option ROM (ie. you can build it so that it provide *only* a nice SNP), but I'm now sure how and whether the build defaults have changed. According to my (now increasingly vague) memories of the iPXE git log, the iPXE author(s) consider the UEFI PXE boot experience "substandard" in comparison to iPXE, so I believe the "hijacking" can occur quite deliberately, as long as you don't convince iPXE otherwise (with a build option perhaps). Gerd, can you chime in please? As far as I remember, qemu only picks up the ".efidrv" output from the iPXE build process, which should only be the SNP driver. > >> - If you want to use the builtin driver despite qemu preloading (by > >> default) the iPXE OpRom, use the following option: > >> > >> -device e1000,netdev=net0,mac=00:00:e8:01:02:03,romfile= > >> ^^^^^^^^^ > >> > >> -device virtio-net-pci,netdev=net0,mac=00:00:e8:01:02:03,romfile= > >> ^^^^^^^^^ > > Yes, I discovered that option. That's what I used to temporarily load > the efi-e1000.rom from QEMU 1.7.0. If I use the QEMU 1.7.0 version of > efi-e1000.rom with QEMU 2.2.0, everything works as expected. I just want > to understand why the behavior with 2.2.0 is different. I thought maybe > I need to include some additional code to force the PxeBaseCodeProtocol > to load or something. Why PxeBaseCodeProtocol isn't present (or doesn't work as expected) with 2.2's efi-e1000.rom would likely require an analysis of the iPXE commits in the qemu 1.7..2.2 timeframe. :( Laszlo ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
