[ipxe-devel] any details about the state of KEEP_IT_REAL?

[Klaus Espenlaub]

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