Re: [NILO-discuss] Zen and the art of running in real mode

[Michael B. <mb...@fe...>]

On Tue, 8 Mar 2005, H. Peter Anvin wrote:
> > Even setting up descriptors to cover the high memory used by a card
> > doesn't help us in the case of being called in V86 mode, in which case
> > we really are constrained to base memory only.
> Indeed.  I don't see any reason to believe this is a permitted use of
> these interfaces, though, on the other hand it clearly works with stock
> PXE systems on FreeBSD.  I wonder if they require the INT 15h mover API
> to exist.

I wondered that.  They'd presumably have to implement their own version, 
since the BIOS version would presumably try to do a mode switch, which is 
forbidden.

> > I think that providing a compile-time option to generate 16-bit code
> > designed to run in real mode (as I described previously) is viable.  
> > There are restrictions: most significantly, drivers that use
> > memory-mapped I/O (readX/writeX) rather than inX/outX probably won't
> > work.  Some drivers (e.g. prism2_pci) can probably be modified to use
> > inX/outX.  Some drivers (e.g. depca.c) seem to use readX/writeX to
> > access normal in-memory data structures; I'm not quite sure what's
> > going on here.
> Well, you could use either the INT 15h AH=87h API, or some clever
> descriptor mangling (for the case of 16-bit PM) to support those
> operations.

It's an option, but for now I think I'll adopt the position that if we 
assume we're allowed to access high memory, we may as well assume that we 
can switch to pmode and do it the easy way.

> > The PXE protected-mode entry point is actually a hack designed to
> > allow 16-bit real-mode code to be called in protected mode.  Code
> > capable of being run in real mode will work when called via the
> > protected-mode entry point, provided that we load %ds etc from the
> > !PXE structure on entry.  Since our code is 32-bit code coerced into
> > 16-bit opcodes using .code16gcc, we're already using %esp as the stack
> > register, so supporting the EntryPointESP is a no-op, and we just need
> > some glue logic to zero the high word of %esp in order to support the
> > (mandatory) EntryPointSP with the same code.
> 
> Actually, you'll have to reload the %ss selector; the default sizes of 
> stack operations are dependent on the stack segment descriptor.  The 
> easiest way to deal with this is to switch stacks:

Good point; I'd forgotten that it depended on %ss.  Thinking more about 
it, we need to have %ss == %ds when we're executing our code anyway, which 
means we'd have to do a stack switch analogous to the pmode/rmode switch 
I've currently got implemented.

One subtlety is that we then have to make sure that we *don't* pass
control to the NBP with our internal stack, otherwise we get screwed at 
re-entry.

> > Since protected-mode operation is so poorly-defined, I strongly
> > suspect that no existing programs ever attempt to call a PXE stack in
> > protected mode.
> 
> People *do* call the UNDI stack in protected mode.  I am not sure if
> there is another entry point to the UNDI stack, or how widely it's used.

Who does?

Michael