Date: Thu, 6 Nov 1997 19:58:34 -0800 From: Jonathan Mini <j_mini@efn.org> To: Tony Overfield <tony@dell.com> 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: <19971106195834.34457@micron.mini.net> In-Reply-To: <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com>; from Tony Overfield on Thu, Nov 06, 1997 at 03:04:48PM -0600 References: <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
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... 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) > 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? > >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. > 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 : 1) The memory which is in the 0x1000 - 0xa0000 (i.e. the 640k of 'conventional memory') is being used by the VM system. God only knows what's there. If we 'pop' back into real mode, we're going to have to reserve some of that. The 'reserved memory' could get quite big. For example, I have some code which uses VESA VBE 1.2 to dump a linear framebuffer to a video card, and it does this by dropping into a vm86 task with the majority of the first 1M mapped with the 600k framebuffer so that it can dump it. This is the only efficient way to do that, and if I had implmented some 'pop back to real mode' reoutine (which i didn't for later reasons) I would have had to reserve the entire first meg if real memory. As it is, I can jump mmap what I need and let the kernel handle alocting it out of the VM system, as it should be. 2) What happens if you're in real mode, and an IRQ is received? You can't loose that IRQ, and often BIOS services take a long time, so the possibility of receiving an IRQ while performing a BIOS service is extremely high. What you need to do is put in interrupt handlers for all IRQs in the real mode interrupt vector table, and then jump back into protected mode to handle the irq in the kernel, and then jump back into real mode to finish the BIOS action. This takes a _long_ _time_ and is generally evil. Half of the headache in DPMI is due to catching irqs and sending them the appropriate processor state. I should also mention that because of this, the entire performance gain of dropping to real mode was lost due to the time it took to drop to real mode, and the leave again. 3) You can't run multiple BIOS calls at once when dropping to real mode. In fact, you can't do _ANYTHING_ else once within real mode. If the BIOS decides to halt the system, you're hosed. There's not much you can do about it. On the other hand, a VM86 task would be given an exception 13 when the BIOS ran a hlt intruction. (I relise that the BIOS by nature is not re-entrant. However, there are several BIOS's we are dealing with. e.g, one on our video card, one on our SCSI card, etc. It is possible to make a call to the video BIOS while peforming a call to the SCSI BIOS with no problems.) 4) There are also no protection limits in real mode. If the code accidentally writes to the wrong section of memory, you could be eating ANYTHING, from another process's dataspace to a filesystem buffer that's waiting to be written to disk. This is a Bad Idea. It ruins the idea of a protected system. A vm86 kernel-thread (or set of threads) is a much better solution over dropping to real mode. Intel only intended Real Mode to be used on the i386+ to initialize the processor for Protected Mode. There are NO reasons to go back to real mode once you are in procected mode. That's why Intel created the vm86 task class. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971106195834.34457>