Date: Mon, 10 Nov 1997 03:57:17 -0600 From: Tony Overfield <tony@dell.com> To: Jonathan Mini <j_mini@efn.org> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, Chuck Robey <chuckr@glue.umd.edu>, Mike Smith <mike@smith.net.au>, Terry Lambert <tlambert@primenet.com>, jamil@trojanhorse.ml.org, hackers@FreeBSD.ORG Subject: Re: >64MB Message-ID: <3.0.3.32.19971110035717.00704df0@bugs.us.dell.com> In-Reply-To: <19971106195834.34457@micron.mini.net> References: <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com> <Pine.BSF.3.96.971106073452.7018C-100000@picnic.mat.net> <199711061242.XAA00382@word.smith.net.au> <Pine.BSF.3.96.971106073452.7018C-100000@picnic.mat.net> <19971106094616.51849@hydrogen.nike.efn.org> <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 07:58 PM 11/6/97 -0800, Jonathan Mini wrote: >Tony Overfield <tony@dell.com> stands accused of saying: >> >yep... I've heard of this (they called it Un-real mode :) )... but >> >basicly you set your registers to a 4gig limit instead of the 64k limit >> >that they have normally... I've bounced your message, Mike, to a friend >> >of mine (Jonathan Mini) who will be able to help with this... Sorry, I didn't say that, but I don't disagree with it. ;-) > Oh. My queue : > > There's nothing Magical about 'Unreal mode' at all. All you do is pop >yourself into protected mode real quick, and then do one of two things : > > 1) set the descriptor limits for all of your registers to the > maximum value (2^32, or apx 4G) and then return to real mode. > > 2) create a vm86 TSS which contains a descriptor with a limit > of > 1M, and a 1:1 page map against the real memory. > > Once you are back into real/vm86 mode (the difference doesn't matter), >you simply address the data in the 'out of bounds' area by using the 32bit >offset and index registers. > There's nothing magical about it, I don't know why everyone acts like it's >black voodoo magic. (This all reminds me of the magic around DOS TSRs in the >really old days and then 'Mode X' (non chain-4 256c VGA modes) Uh, no kidding, me too. ;-) I did say this, however: >> Sorry for this useless diversion. It seems my question was ambiguous and >> that Mike took it the other way. I recommend against using this "unreal" >> mode trick. > > Why? This was a response to a question about the FreeBSD bootloader, and it isn't what I was wanting to talk about, but you did ask, so... First, it's entirely wrong for the application. The bootloader is a use32 protected mode program. It makes transitions to real mode for BIOS calls only. There's simply no need to address extended memory from real mode. Second, to me it seems a little bit silly to pop into protected mode then back to real mode just so you can avoid protected mode. I realize that there still exists some real-mode code that needs quick access to video frame buffers and such, but that's another topic. Third, it doesn't always work. Any time you give up the CPU to another piece of code (ostensibly BIOS code), especially in real mode, there's a chance that that code might take a brief trip into protected mode and when it exits it might reload your descriptors with bonafide real-mode compatible ones. Of course, you can fix them up when necessary, if you know when they are clobbered. Of course, I'm not aware of any BIOS that does this, but other BIOS "hookers" could be there, particularly in the case of the DOS version of the bootloader. I have seen instances where a timer or an asynchronous disk interrupt (yes, in DOS) has occurred that resulted in a "real-mode" task-switch and an interrupt-time reentry into INT 13h. If the INT 13h function were to reload the descriptors before returning, you would lose your big limits at an essentially unpredictable time. (NCACHE.EXE for you die-hard types.) >> >he was quite surprised that we kept flipping between real and protected >> >mode when he first saw the boot blocks... >> >> I wonder why. I don't see anything wrong with flipping into and out of >> protected and real modes. After all, it needs to be done. > > No, it doesn't need to be done, and the boot blocks eat a serious >performance loss doing it. Well, I'll have to strongly disagree here. Last time I measured this, I was able to switch from protected mode to real mode and back well over 100000 times per second (236000 times/sec in my last test). That's without A20 gate toggling, of course. If you include A20 gate toggling, any imagined disadvantage of mode switching disappears entirely into the noise. Sure, it's a lot slower than "mov reallybigpointer, %ebx" but it's not slow enough to make any difference. I simply don't believe 1) that the booloader does enough of these to matter, and 2) that anyone really cares about the performance of code that runs for less than one second per boot (on my systems, at least). On every system I've seen, the bootloader spends most of that second either waiting for I/O, or doing I/O. >> My ambiguous question reworded would say... >> >> Once you are in the kernel startup code and running in protected mode, >> why not simply switch back to real mode for BIOS calls and etc. instead >> of trying to set up a VM86() facility? I think it's easier and much >> better for compatibility while booting. > > There are four reasons : [Four good, irrelevant, and deleted reasons...] Well, I'm fairly familiar with each of these bad things you've mentioned, but it seems that I cannot keep the discussion centered around the original topic. I have never suggested that real-mode be entered for BIOS calls after the kernel has actually take over the VM, the IRQs, or the control of devices. Specifically, I was talking about what happens or could happen during the bootstrap process; the time before, during, and very slightly after the kernel is loaded into memory. In the context of bootloaders, it was suggested that because the bootloader is completely out of space, that some (or even most) of the things that one might like to locate in the bootloader should instead be dragged into the kernel to be performed there. The assumption I made (am I the only one who made this assumption?) is that the code moved to the kernel is run almost immediately after the bootloader jumps to the kernel. This is at least logically similar to it being an extension of the bootloader. After the bootloader loads the kernel into memory, it jumps into it. The part that bothers me is that people want that instant in time to be a magical instant where you cannot call the BIOS in real mode anymore after having done so several thousands of times up to that point. Just because it's now running the "kernel" doesn't mean anything other than a jump (lret, in this case) has actually occurred. I was arguing that there is no reason for things to work differently (i.e. no real need for vm86()), until after the booting process has been completed and the kernel "proper" begins execution. - Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19971110035717.00704df0>