[ipxe-devel] iPXE download protocols via EFI effort

[Geoff Lywood]

----- Original Message ----- 

> From: "Jarrod Johnson" <jarrod.b.johnson at gmail.com>
> To: "Geoff Lywood" <glywood at vmware.com>
> Cc: ipxe-devel at lists.ipxe.org
> Sent: Friday, August 12, 2011 9:32:24 AM
> Subject: Re: iPXE download protocols via EFI effort

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

I think the VMware bootloader should be ok with that. Have you tried it both ways and found that it worked when you used a separate handle, but did not work when everything was on the same handle?

Can you give any more details as to what exactly is happening? Is it failing to load files with an "error 4: unsupported"? Or something else? I might be able to give you some insight, or maybe source code off-list, under the same NDA that gives you early access to ESXi. Note that VMware's EFI bootloader contains some GPL code, so we have to release the full source once vSphere 5 is public.


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

One thing to consider is that architecturally, iPXE is designed to support multiple network cards. I doubt very many people seriously use that feature, but it exists. If there are multiple underlying devices, it's not obvious which handle to attach to. (That's my opinion, but you are welcome to prove me wrong.) I agree that for snponly.efi it doesn't matter much either way.


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

Yes, I suppose you would have to do that in order to support the needs of elilo. But like I said above, I think the VMware bootloader should work if you're using the same handle. (In fact, it should work better, because we have some logic to automatically detect the MAC address during a network boot, and that will only work if the Simple Network Protocol is present.) We obviously haven't tested this scenario, though, so anything might happen.

If you want to throw a pre-built iPXE bin-x86_64-efi/snponly.efi my way, I can probably spend an hour or two and figure out exactly what's going wrong.

Thanks,
Geoff



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