Re: [Qemu-devel] [edk2] syslinux vs. OVMF

[Laszlo Ersek <lersek@redhat.com>]

On 05/26/15 16:36, Michael Tokarev wrote:
> 10.04.2015 13:06, Laszlo Ersek wrote:
>> On 04/10/15 10:14, Gerd Hoffmann wrote:
>>>   Hi,
>>>
>>>> In summary, please ask Gerd to rebuild the ipxe binaries that are
>>>> bundled with upstream qemu such that they include those two iPXE patches
>>>> of ours (see the last reference).
>>>
>>> https://www.kraxel.org/cgit/qemu/log/?h=rebase/roms-next
>>>
>>> Can you give this a try?
>>
>> Thank you for this update, I tested it.
>>
>> (1) I reproduced the issue, so that I could be sure that the fix wasn't
>> meaningless. Indeed the bug reproduces with the iPXE binaries bundled
>> with upstream qemu.
>>
> []
>> * e1000 results:
>> - OVMF        loads shim.efi    via network
>> - shim.efi    loads grubx64.efi via network
>> - grubx64.efi loads grub.cfg    via network
>> - grubx64.efi loads vmlinuz     via network
>> - grubx64.efi loads initrd.img  via network
>> - guest kernel boots
>>
>> So, I think the update is fine in general...
> 
> However, after the update of efi roms in qemu, the original problem
> of booting syslinux in OVMF still persists.  I received several
> private messages asking whenever I succeeded in resolving the
> original prob outlined at
> 
>  http://www.syslinux.org/archives/2014-November/022804.html
> 
> and I always referred to this thread, until someone told me that
> the update does not fix the issue.  Now I verified it locally,
> and no, I still can't use syslinux with OVMF with qemu efi roms,
> getting exactly the same output as I've seen on Nov-2014.

If you are getting *exactly* the same output as in the message
referenced above, complete with the iPXE banner, then you're not using
the right (updated) iPXE binaries. (I think Gerd's patches implementing
the update have not been merged into upstream qemu yet? The most recent
patch from Gerd, under pc-bios/, is
c246cee4eedb17ae3932d699e009a8b63240235f. Unrelated, and too old.)

I'm saying this because, if you had everything in place, then the iPXE
banner would *not* be printed. iPXE would not hijack the boot flow "as
usual", it would only provide an SNP (Simple Network Protocol)
implementation for edk2's network stack (including the PXE base code
driver). And the iPXE banner would be absent.

To summarize, I've found three bugs in iPXE thus far:

- the EFI_SIMPLE_NETWORK_PROTOCOL.Transmit() and .GetStatus() interfaces
are not correctly implemented. This trips up at least grub. Fixed by
"efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec"
patch; not taken by upstream.

- iPXE's own EFI_LOAD_FILE_PROTOCOL implementation causes edk2's PXE
base code driver to become inactive / useless. See the discussion in
<http://lists.ipxe.org/pipermail/ipxe-devel/2015-February/003979.html>.
Fixed by "make load file protocol optional", and "ipxe: disable load
file protocol". Not taken by upstream. This is the bug that you are
still running into, most likely.

(The iPXE banner is printed in ipxe(), "src/usr/autoboot.c", via the
macro PRODUCT_TAG_LINE and its friends. The ipxe() function is not
called after these patches, because its caller, efi_snp_load_file(), is
never reached either.)

- NIC driver not torn down at ExitBootServices(). Fixed by (one month
old) upstream iPXE commit 755d2b8f. This bug becomes a problem only when
you actually start a runtime OS, and even then it is very sensitive to
memory layout.

Earlier I received reports about syslinux 6.03-pre20 working nicely with
OVMF's builtin virtio-net driver:

http://lukas.zapletalovi.com/2014/09/efi-in-qemu-kvm-on-fedora-20.html

Can you please verify that on your end? (Disable iPXE oprom loading with
"-device virtio-net-pci,romfile=".) That would at least narrow down the
troubles.

> As you checked, grub loads, but apparently syslinux still doesn't.

I guess I'll have to set up syslinux too, and see it for myself. ;)

> Is it a different issue perhaps?

We'll see.

Thanks
Laszlo

> Thanks,
> 
> /mjt
>