On 12.06.2012 13:49, Michael Brown wrote:
On Monday 11 Jun 2012 18:40:39 Klaus Espenlaub wrote:
we're working on updating the PXE support in VirtualBox to iPXE, and had
to realize that the KEEP_IT_REAL support is broken. Does anyone know how
far away it is from working state? Didn't find any information in the
ipxe mailing list except
http://article.gmane.org/gmane.network.ipxe.devel/66 - funnily again
talking about VirtualBox.
It's the only relevant mode of operation which conforms to the PXE spec
(so I was rather surprised that it's not working). It's vital for many
DOS/Windows based or completely custom professional deployment solutions
which expect the PXE stack, especially UNDI, to work from real mode, V86
mode or 16bit protected mode.
So if iPXE wants to replace both Etherboot (which is also broken in this
respect) and Intel PXE in VirtualBox this apparently otherwise unused
feature will have to be resurrected. We're aware that this means kicking
out any feature which isn't vital, and that's not a concern since in the
worst case the people who need a more feature rich iPXE build can
replace the ROM image, or use the simple one to bootstrap a build over
the network which has everything enabled.
I forgot to mention that this doesn't have to work here and now, it's
just something we need working before we can even start considering what
we need to do/test before removing the Intel PXE ROM binary which is
used by default if the VBox extension pack is installed.
In the many years since I first implemented KEEP_IT_REAL, this is the first time
that anyone has expressed any substantial interest in it. I have personally
never come across a deployment product that requires KEEP_IT_REAL. Even the
most internally convoluted (Tivoli, which uses VM86 mode and ring 1) manages
to work with iPXE as-is.
Interesting and strange at the same time - anything using VM86 can't use
the normal code sequence for switching back to protected mode
(real_to_prot).
This is only relevant for the case where the OS which was booted through
PXE wants to continue using PXE services (such as UNDI). Generally there
is a workaround (using the actual NIC driver instead of the generic one
using UNDI), but that's very ugly.
I have only ever encountered one NBP that would require KEEP_IT_REAL: the PXE
loader from one of the BSDs (might have been OpenBSD).
Support has been allowed to wane since no-one seemed interested and nothing
seemed to actually require it. However, I've been fairly strict in retaining
a memory model that would allow it to be resurrected; hence the (otherwise.
artificial) separation between void * and userptr_t. The build architecture
introduced to handle EFI (and later Linux-native binaries) is also designed to
accommodate a KEEP_IT_REAL platform.
Great... personally I'd prefer sticking to 32bit code (because gcc sucks
at creating 16 bit code), but unfortunately there isn't much choice in
the long run.
Resurrecting support should be reasonably straightforward.
That's good to know. We'll probably look into this. From a first peek
it's not that much work. The biggest problem seems "bit rot" in
i386-kir.lds, which uses different symbol names and lacks a significant
number of symbols referenced by the rest of iPXE. Of course always
keeping fingers crossed that the relocation nagging by the linker is
mostly harmless (or due to exceeding the 64K size limit).
Thanks for the encouraging information,
Klaus
Michael
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
