Using Unreal Mode

[AJ]

Hi,

I am currently taking a break from my kernel and having a look at CBoot, which currently takes over from GRUB and loads my kernel directly in 64 bit mode (with a nice information structure and a switch to a VESA video mode). The time has come to make CBoot self-supporting, so I am writing a first stage loader.

The question is whether to use unreal mode, or switch between PMode and Real Mode when I am loading my kernel. Unreal mode is perhaps a little easier (once I am there, I can stay there and load my data above 1MiB), but it makes me a little uneasy using a mode which is essentially not using the CPU as it was originally intended. I would eventually like others to be able to use CBoot as a stand-alone product (freeware!).

Are my worries unfounded? Am I better off taking the time to switch back and forth between real and protected mode for kernel loading? Could Unreal mode even become unsupported in future (unlikely, I know)?

Any thoughts appreciated.
Cheers,
Adam

[Combuster]

Unreal mode has been shrouded in mysteries for a long time. That doesn't mean it has been demystified over the years.

One of the concerns that might be is the fact that in the future, BIOS calls may enter protected mode of their own, and when they return, you're no longer in unreal mode, but in boring real mode. Which means that you have to enable unreal mode once again. To be robust against such behaviour, switching between rmode and pmode is indeed best practice.

But right now I'd worry more about EFI and friends

[Ready4Dis]

Unreal mode will not be dropped anytime soon. If it was going to get dropped it would have by now, and no worries about the standard bios interrupts going to pmode and coming back, they are written in such a way that they are valid in v86 mode, which means they can never enter pmode, if they do try to enter pmode, then v86 mode will no longer be supported, in which case, real-mode probably is no longer supported, so this would be a moot point anyways. I was staying away from unreal mode for the same reasons, but then figured it didn't really matter, and my code runs fine on newer amd64 chipsets just fine (outside of it not returning a good e820h map from the bios, but that's a different issue). I now use unreal mode in my bootloader without issue on any new hardware thus far (to include p4 hyperthreaded cpu's, amd64 chipset, etc). I have done a lot of reading on unreal mode before making the transition (I used to switch back and forth), and it doesn't seem like it will be removed anytime soon (well, as long as v86 and real mode are around). Switching back and forth (in comparison to the disk access) doesn't take very much extra time, but it's still a few extra clocks and bytes from the bootsector to remove .

[Dex]

I have used going to and from pmode to real mode without any problems, so i would use that.
But unreal mode would probably work just as well.

[AJ]

Thanks,

I think that given Combusters point about the possibility of the BIOS reloading segments with 16 bit descriptors, I am best sticking with PMode <--> RMode transitions, despite the slight increase in complexity.

Adam

[jal]

the standard bios interrupts going to pmode and coming back, they are written in such a way that they are valid in v86 mode, which means they can never enter pmode, if they do try to enter pmode, then v86 mode will no longer be supported

This is of course utter bullshit. To fully support the BIOS in v86 is a pain, that's why we limit it to calling int 10h. CPU vendors != BIOS vendors != OS vendors. v86 support is a processor thing (already dropped in long mode), and there's no 'support' to be made for BIOS and vice versa. Besides, some BIOS calls may even switch to PM already, there's nothing preventing them from doing so.

As for long mode, I'm pretty sure that SMM uses it (I recall some remark about SMM running in real mode with access to 4GB address space in the Intel manuals).


JAL

[jal]

I think that given Combusters point about the possibility of the BIOS reloading segments with 16 bit descriptors, I am best sticking with PMode <--> RMode transitions, despite the slight increase in complexity.

Combuster said "in the future may" (or something), but I doubt this. In the future we'll have EFI and the like. The real mode interrupts you'd be calling in your boot loader are very likely not to switch to PM ever. You could even have a wrapper around BIOS calls to make sure you stay in long mode. This also would mean Pmode to Rmode switches, but at least there's no complexity in code.


JAL

[Ready4Dis]

Thanks,

I think that given Combusters point about the possibility of the BIOS reloading segments with 16 bit descriptors, I am best sticking with PMode <--> RMode transitions, despite the slight increase in complexity.

Adam

Well, it is possible, and I'm sure there may be some bios function that uses rmode somewhere, but the ones that you are using in the boot loader (int 13h) haven't been known to do this for compatibility reasons (there are to many OS's/applications that rely on v86 mode to drop support for it). It doesn't hurt to be cautious, and the latency of the disk i/o will completely overshadow the time it takes to switch back and forth (I used to do it, doens't seem to have changed boot times much at all), especially if you do it in such a way that you load large sections at a time (multiple sectors), then copy in large blocks (say, 64k at a time to not have to cross a boundary/play with a segment register during the reads). If you do 64k at a time, even if your kernel is 1mb, that's only 16 switches back and forth (32 switches total 16->pmode, 16->back rmode), considering how long it takes to read 128 sectors (64k/512 bytes=128), the switch time will barely make a dent and it's safer. I chose the other route due to it's time and space savings (trying to keep my bootsector small as possible), and haven't had issues on any systems yet (well, no issues related to unreal mode .