Real Mode -> Long Mode, Directly or Indirectly?

[sandras]

Hi,

Should I switch from Real Mode to Long Mode Directly or through Protected Mode? Is there a difference? Am I missing out on something by switching directly? I've read about an NMI occuring right after entering Long Mode causing the code to crash. Can't I just disable NMIs for the moment?

Thanks.

[iansjack]

http://wiki.osdev.org/Entering_Long_Mode_Directly

(As an aside, an NMI is what its name says - non-maskable.)

[sandras]

I'm a noob and I don't know if disabling and masking is the same, but http://wiki.osdev.org/NMI says you can disable NMI.

[Korona]

Disabling the NMI seems to be the only option to be safe until an IDT is set up, regardless of the method that you use to switch modes. Note that while disabling the NMI via port 0x70 is not architecturally defined, even modern Intel chipsets support it, so it is probably fine to rely on it.

[sandras]

Now that's something useful. Thanks!

[linguofreak]

I'm a noob and I don't know if disabling and masking is the same, but http://wiki.osdev.org/NMI says you can disable NMI.

Note that that same article says that NMIs only occur on critical hardware failures or when a watchdog timer fires. A watchdog timer won't fire unless you've already set it up, so assuming you don't do that before you're in long mode, the only reason you'll take an NMI at this point is non-recoverable hardware failure. It's highly likely that whatever instruction is currently executing at the time the NMI is raised won't successfully complete in any case, or will do so with bogus results (for example, if a RAM error occurs during a read, there may not be valid data on the bus. If that read is an instruction fetch, the data on the bus may not be a valid instruction, so in that case you'll take an NMI if NMIs are enabled, and a invalid opcode fault if NMIs are disabled). While there are uses for NMIs on a running system, such as watchdog timers, that don't necessarily have to do with hardware failure (in which case the OS is more or less expecting them and has likely configured the hardware that generates them), an unexpected NMI at boot is just the hardware's last ditch attempt to let you print a useful error message to go with the lovely crash that is already guaranteed to occur. That may not even succeed in the best of cases: your NMI handler might be in the middle of the RAM module that just failed, or the power supply may have failed and delivered a nasty power spike to the motherboard and killed everything, or any number of things like that. You should try the best you can to handle NMIs at boot, but they mean the system has effectively already crashed, and may not even be able to run your NMI handler anyway, so you shouldn't worry too much about them occurring in the brief window during the switch to long mode where they will crash the system. Whether you disable them or leave them enabled, you likely won't finish booting either way.

[sandras]

Good point, linguofreak. I'll consider that when designing and implementing.