[ipxe-devel] iPXE download protocols via EFI effort

[Jarrod Johnson]

Forgive me if I suggest some nonsensical stuff, I confess to still not fully
understand all the aspects of EFI.

So as I continue, I toyed with the idea of installing the ipxe download
protocol to the loaded image device handle instead of making a brand new
handle .  However, this seemed to confuse VMware's boot loader somehow, and
it failed to use the ipxe download protocol correctly when I tried that.
 What might VMware's boot loader be assuming that is broken when the same
device handle that was used to load iPXE is used to load bootx64.efi after
installing the ipxe download protocol?

The reason why I was tempted is that would preserve some things currently
lost on the boot device handle since the new boot device handle has only the
ipxe download protocol itself right now.  For instance, being able to call
device path protocol on the boot handle to extract mac address instead of
relying upon argument list.  Also, the ability for something like elilo's
netfs to be modified to use ipxe_download and fallback to pxebasecode with a
lot of the non-transfer code left intact and not duplicated.  I suppose
netfs.c could be modified to search first for the ipxe download protocol
handle, and then add a call to the download protocol to get the original
boot handle, but I think that could be messy compared to the simplicity of
using the same handle for all the protocols.  The alternative would be to
write a whole new module (my first thought) with some amount of duplicated
code and such.

If I cannot really reuse the boot device handle, then I'll have to flesh out
the new handle in a few ways.  Cloning the loaded image device path and
either adding a way to get the 'real' boot handle or else duplicate data as
needed (though the latter means potentially a lot of work and without
knowing what confuses vmware's boot loader, I'd be likely to induce the same
behavior anyway.
On Wed, Aug 10, 2011 at 3:13 PM, Geoff Lywood <glywood at vmware.com> wrote:

>
> ----- Original Message -----
>
> > From: "Jarrod Johnson" <jarrod.b.johnson at gmail.com>
> > To: ipxe-devel at lists.ipxe.org, "Geoff Lywood" <glywood at vmware.com>
> > Sent: Wednesday, August 10, 2011 6:29:53 AM
> > Subject: iPXE download protocols via EFI effort
>
> > On my tree, I'm porting forward some changes from Geoff Lywood to
> > give iPXE the ability to install EFI protocols that chainloaded
> > bootloaders can use to get http and such. My goal is a sort of
> > 'ielilo' reminiscent of 'ipxelinux' in 'legacy' land. The biggest
> > question I have to date would be if the uninstall of the protocol
> > should happen where it does, or move to efi_init like the nic
> > shutdown code did when Itay modified it...
>
> > Hopefully I'll have something workable for review by end of day (need
> > to port over Geoff's cmdline construction which includes populating
> > a handle that is needed to keep elilo from hanging like it does with
> > ipxe today).
>
> > My next step would be an 'ipxefs' in elilo code to create a
> > filesystem 'protocol' over the ipxe protocol in the same way 'netfs'
> > constructs one over pxe base code. I briefly contemplated whether it
> > would be possible to implement netfs protocols and elilo would 'just
> > use it' without code change or even recompile, but decided that
> > could be a bad idea even if possible.
>
>
> For the record, I did put some amount of thought into trying to make iPXE
> expose a protocol that is defined in the UEFI spec. The options were:
>
> EFI_LOAD_FILE_PROTOCOL: This is unsuitable because it involves loading from
> a device path. It is difficult to pack a URL into a device path without
> either defining a new device path node type, or breaking the rules around
> device path file name formatting (which prohibit a "//"). In either case the
> client would have to be modified. Additionally, at least for VMware, we
> wanted a smooth progress bar, and the all-or-nothing nature of this protocol
> meant loading several hundred megabytes over the network with no user
> feedback.
>
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL: This does not work because it requires the
> ability to seek and such. TFTP just doesn't support the operations
> necessary.
>
> EFI_PXE_BASE_CODE_PROTOCOL: This one probably makes the most sense, but
> it's still not a good fit. This protocol is very TFTP- and MTFTP-oriented,
> and it would be a bit of a hack to try to slip, say, https support in under
> the covers. Some operations on this protocol don't make as much sense under
> iPXE, for example what does a "Discover" operation do, given that iPXE
> supports multiple NICs? And it seemed like a lot of work to expose things
> like the iPXE routing table, ARP cache, and cached DHCP packets up through
> this mechanism.
>
> - Geoff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20110812/24be7e1f/attachment.htm>