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

[Michael Tokarev <mjt@tls.msk.ru>]

26.05.2015 19:49, Laszlo Ersek wrote:
[]
>> 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

No, I mean I see the same error message "Failed to read blocks: 0xC"
after syslinux.efi load.  The banner is new, with a few changed details.

> 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.)

Oh sh*t.  You're right.  Indeed, that's the last patch, and indeed
it is too old.  I guess we need http://lists.ipxe.org/pipermail/ipxe-devel/2015-March/004007.html
or some other bits from https://www.kraxel.org/cgit/qemu/log/?h=rebase/roms-next.

Somehow, since the talk was about updating binaries before the next
(2.3 at that time) release, I thought current qemu have all necessary
bits.

> 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.

Ok.  I do see a banner here, so things doesn't work as they should,
and that's because I don't have the last patches which aren't still
in qemu.

> 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.

Not taken?  Why?  Just time issues or some problem?

> - 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.

Again, why it hasn't been taken?

> (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.

Yes, that one works.  It needs updated OVMF, but that's details,
and you know this already as well.

>> 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. ;)

Nah. there's no need to. Lemme to actually apply the patches and see.

Thanks,

/mjt