4 ms·

The point is that the CPU might still be in real mode at the point in time when the far jump is decoded, and thus execute it with real mode semantics. Coding a

The point is that the CPU might still be in real mode at the point in time when the far jump is decoded, and thus execute it with real mode semantics. Coding a seemingly useless near jump was the way to prevent that. Whoever wrote the modern Linux code doesn't seem to understand any of this. There is even a jump before the switch to protected mode, with the comment "Short jump to serialize on 386/486". Cargo-cult programming at its finest :) As I said before, it may have always worked in practice without the jump, and modern Linux doesn't even support the 386 anymore. Actually, with all the crazy out-of-order speculative execution going on, one could expect newer CPUs to have similar requirements, but I guess they also had to get better at providing the illusion that such internal details don't matter. Making LMSW / MOV CR0 a serializing instruction seems to be an easy way to do it.

knorker 5y ago
> the CPU might still be in real mode at the point in time when the far jump is decoded, It definitely is in real mode when the far jump is decoded. Or is that not the right technical definition of "real mode"? Do we leave real mode as soon as CR0 bit 1 is set, even though nothing has changed until the code puts a new value into a segment register? I've always thought of it as when CS becomes 32bit, meaning the long jump. Anyway, that's just terminology. > "Short jump to serialize on 386/486". Cargo-cult programming at its finest :) That's weird. I tracked down the commit: https://github.com/torvalds/linux/commit/2ee2394b682c0ee99b0f083abe6c57727e6edb69 https://github.com/torvalds/linux/commit/2ee2394b682c0ee99b0... > Actually, with all the crazy out-of-order speculative execution going on I would expect those to detect that dependency and not take effect. But I could be wrong. Edit: Interesting. The new Intel docs explicitly say to do the far jump "Immediately" after setting the PE bit in CR0. https://www.intel.co.uk/content/www/uk/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html https://www.intel.co.uk/content/www/uk/en/architecture-and-t... section 9.9.1. Whereas the example code for the original 386 programming manual has the short jump, many other instructions, and then the far jump. Haha, but then the actual example code on page 9-20 (new manual) still has the "clear prefetch queue" near jump.
- rep_lodsb 5y ago
  >Do we leave real mode as soon as CR0 bit 1 is set Yes, that's what the bit is defined as doing. Protected mode was introduced on the 16-bit 80286, and 16-bit code segment descriptors are still supported to this day. Even in real mode, the segment registers have hidden fields containing base, limit and access rights. The difference is that when they get loaded in real mode, the base will be set to the segment shifted left by 4 bits, with the limit¹ and access rights² generally left unchanged. What the PE bit actually affects is how segment load instructions operate, how interrupts/exceptions are handled, and a few other details. Most instructions run exactly the same microcode in either mode: any memory access will form the address and do protection checks based on whatever is currently in those hidden fields. But a segment load (or far jump) decoded while PE=0 will execute different microcode than one with PE=1. >That's weird. I tracked down the commit Shuffling the code around may have fixed some alignment bug? The jump could likely be replaced by two NOPs, in any case the comment is completely wrong. 2.6.22 seems to be the last version using LMSW followed by a near jump, and presumably worked on that CPU (at least there is a comment mentioning bugfixes for Elan), so it isn't likely to be the cause of the problem. ¹ the limit on power-on/reset is 64K, but it is possible to change it to 4G, allowing access to all memory ("unreal mode") ² CS will always be made a writable data segment, something not possible to set up in protected mode without the use of LOADALL edit: >Interesting. The new Intel docs explicitly say to do the far jump "Immediately" after setting the PE bit in CR0. Well, it's probably not required to do any kind of jump immediately on modern CPUs, but it wouldn't be the first time Intel got something completely wrong: https://www.os2museum.com/wp/sgdtsidt-fiction-and-reality/ https://www.os2museum.com/wp/sgdtsidt-fiction-and-reality/

knorker 5y ago

> the CPU might still be in real mode at the point in time when the far jump is decoded, It definitely is in real mode when the far jump is decoded. Or is that not the right technical definition of "real mode"? Do we leave real mode as soon as CR0 bit 1 is set, even though nothing has changed until the code puts a new value into a segment register? I've always thought of it as when CS becomes 32bit, meaning the long jump. Anyway, that's just terminology. > "Short jump to serialize on 386/486". Cargo-cult programming at its finest :) That's weird. I tracked down the commit: https://github.com/torvalds/linux/commit/2ee2394b682c0ee99b0f083abe6c57727e6edb69 https://github.com/torvalds/linux/commit/2ee2394b682c0ee99b0... > Actually, with all the crazy out-of-order speculative execution going on I would expect those to detect that dependency and not take effect. But I could be wrong. Edit: Interesting. The new Intel docs explicitly say to do the far jump "Immediately" after setting the PE bit in CR0. https://www.intel.co.uk/content/www/uk/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html https://www.intel.co.uk/content/www/uk/en/architecture-and-t... section 9.9.1. Whereas the example code for the original 386 programming manual has the short jump, many other instructions, and then the far jump. Haha, but then the actual example code on page 9-20 (new manual) still has the "clear prefetch queue" near jump.

rep_lodsb 5y ago
>Do we leave real mode as soon as CR0 bit 1 is set Yes, that's what the bit is defined as doing. Protected mode was introduced on the 16-bit 80286, and 16-bit code segment descriptors are still supported to this day. Even in real mode, the segment registers have hidden fields containing base, limit and access rights. The difference is that when they get loaded in real mode, the base will be set to the segment shifted left by 4 bits, with the limit¹ and access rights² generally left unchanged. What the PE bit actually affects is how segment load instructions operate, how interrupts/exceptions are handled, and a few other details. Most instructions run exactly the same microcode in either mode: any memory access will form the address and do protection checks based on whatever is currently in those hidden fields. But a segment load (or far jump) decoded while PE=0 will execute different microcode than one with PE=1. >That's weird. I tracked down the commit Shuffling the code around may have fixed some alignment bug? The jump could likely be replaced by two NOPs, in any case the comment is completely wrong. 2.6.22 seems to be the last version using LMSW followed by a near jump, and presumably worked on that CPU (at least there is a comment mentioning bugfixes for Elan), so it isn't likely to be the cause of the problem. ¹ the limit on power-on/reset is 64K, but it is possible to change it to 4G, allowing access to all memory ("unreal mode") ² CS will always be made a writable data segment, something not possible to set up in protected mode without the use of LOADALL edit: >Interesting. The new Intel docs explicitly say to do the far jump "Immediately" after setting the PE bit in CR0. Well, it's probably not required to do any kind of jump immediately on modern CPUs, but it wouldn't be the first time Intel got something completely wrong: https://www.os2museum.com/wp/sgdtsidt-fiction-and-reality/ https://www.os2museum.com/wp/sgdtsidt-fiction-and-reality/