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

[Laszlo Ersek]

On 05/26/15 19:04, Michael Tokarev wrote:
> 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.

Interesting -- no clue where "Failed to read blocks" comes from. Not
syslinux, not iPXE, not shim, not grub, not edk2, not the kernel...

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

Gerd's "rebase/roms-next" branch should be all right, except it should
incorporate an update to iPXE 755d2b8f too, not just the earlier dc795b9:

$ git log --oneline --reverse dc795b9..755d2b8f | cat -n
 1  b12b1b6 [virtio] Downgrade per-iobuf debug messages to DBGC2
 2  a9da129 [test] Simplify digest algorithm self-tests
 3  4dbc443 [crypto] Add SHA-224 algorithm
 4  6f713c2 [crypto] Add SHA-512 algorithm
 5  0287929 [crypto] Add SHA-384 algorithm
 6  e5e91ab [crypto] Add SHA-512/256 algorithm
 7  ea3d587 [crypto] Add SHA-512/224 algorithm
 8  755d2b8 [efi] Ensure drivers are disconnected when
            ExitBootServices() is called

755d2b8f is the relevant commit. (Mentioned below.)

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

There was a little discussion in
<http://lists.nongnu.org/archive/html/qemu-devel/2015-04/msg01216.html>,
but the series was not merged.

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

I don't know. No feedback on ipxe-devel. On IRC, the maintainer seemed
to lean towards accepting this patch, but ultimately it didn't go anywhere.

Gerd has repeatedly posted this patch to ipxe-devel (I really couldn't
handle the stress any longer, caused by the lack of maintainer
responsiveness, so I gave up -- thanks Gerd for picking it up!)

So, short answer: "no clue".

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

Two reasons, in my perception:

(a) It implements the polar opposite of how the iPXE maintainer sees /
positions iPXE. "We" (well, "I", definitely) want iPXE to provide a low
level network driver for the edk2 network stack, for QEMU NICs different
from virtio-net, and then get out of the way

Whereas the iPXE maintainer wants to provide users with the traditional
iPXE user experience, and in his opinion the edk2 network stack comes up
short in that regard -- refer to iPXE commit c7c3d839. For that end,
upstream iPXE basically hijacks the boot flow when it gets control from
the UEFI firmware, and does (in practice) what it does on legacy BIOS
systems.

(b) When I found out above the above trick in iPXE, I got quite angry,
and used somewhat inflammatory (and inexact) language in the public BZ,
and in the patch that I submitted to ipxe-devel. (In fact I think my
first patch just reverted c7c3d839.) That wasn't smart, probably.

Nonetheless, Gerd has since addressed these issues -- he made the code
in question build-time tweakable, matching the prior configuration
infrastructure of iPXE. No more angry commit messages, just some
refactoring for iPXE upstream, and flipping a macro for downstreams
(that want iPXE to provide a low level network driver and nothing else).
Plus, I provided a full analysis of the issue on ipxe-devel (link above
in the quote).

Unfortunately, even this approach got stuck on ipxe-devel.

>> (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, I'm curious. In fact, for a quick test, you can simply grab the
iPXE binaries from Gerd's rebase/roms-next branch. They won't include
iPXE commit 755d2b8, but that bug has potential to cause problems only
much later than where you're stuck now.

Cheers
Laszlo