Unreal 64 Mode????

[tom9876543]

Hi

As people were debating unreal mode, I thought, what about computers with more than 4GB????

Does anyone know if it is possible to set the segment limit to 64bit on AMD64/Intel64 processors and return to real mode?

Even then, I don't think its possible to reference 64 bit registers RAX etc in real mode?

How does the BIOS / SMM work on 64 bit CPUs? Do they ever need to save the entire RAM (including over 4gb?)

[IanSeyler]

I would say that this is not possible. Also you must be in 64-bit mode to access to 64-bit extended registers.

[Combuster]

I think it has something to do with the fact that Long Mode ignores the limit fields (and for most registers the base as well) instead of filling out the descriptor caches...

[tom9876543]

Hi

I did a bit of research, and AMD could have easily implemented an "unreal 64 bit mode".

AMD Long mode allows you to modify the FS and GS base using WRMSR (write model specific register).

Here is my idea of how AMD should have designed it. It only requires 2 new instructions WRFS and WRGS.

WRFS

Opcode: OF 36

Description:
mov FS_SEG_LIMIT, 2^64-1
mov FS_SEG_BASE, qword [(R/E)AX]

Supported modes: Real Mode, Protected Mode and Long Mode

Exceptions: Can only be executed when CPL=0

WRGS Same for GS, opcode 0F 37

Then you could access the entire address space in real mode (as well as 32 bit protected). I think this is much more flexible than the AMD design. Of course, I am no expert!

Code: Select all

; Assume 16 bit real mode

; Simple code to copy 4096 bytes from anywhere in 64 bit address space

xor esi, esi   ;Encodes to 66 31 F6
xor edi, edi   ;Encodes to 66 31 FF

mov ax, source_addr      ;Assume source_addr is a 64 bit pointer for start of memory block
wrfs                              
mov ax, dest_addr         ;dest_addr is 64 bit pointer
wrgs                             

loop_start:

cmp esi, 4096     ;Encodes to 66 81 FE 00 10 00 00
jge done

mov edx, [fs:esi]    ;Encodes to 64 66 67 8B 16
mov [gs:edi], edx    ;Encodes to 65 66 67 89 17

add esi, 4           ;Encodes to 66 81 C6 04 00 00 00
add edi, 4           ;Encodes to 66 81 C7 04 00 00 00

jmp loop_start

done:

nop

[Combuster]

No they can't change that.
It would break the GDT trick.

(apart from the dozen bugs in that code snippet)

[Ready4Dis]

We need to stop supporting real mode, drop it 100% and just go with pmode and long mode . I hate all this backward compatibility, makes things way more complicated than they have to be.

[NickJohnson]

I did a bit of research, and AMD could have easily implemented an "unreal 64 bit mode".

But why would you even want to do something like that? Unreal mode is only ever used in bootloaders for convenience of using the BIOS, but I'm assuming no kernel will ever exceed 4 GB in size (or at least I hope: it seems like a monolithic kernel that big would collapse somehow).

[Love4Boobies]

That's indeed the point - unreal mode is usually used in boot loaders. Now take a look at GRUB - soon 4 GiBs won't be enough so they'll need something like 64-bit unreal mode. </sarcasm> Did you see all the crap they're adding in? Network drivers? Rewriting parts of firmware? How's any of that related to boot loaders?

[Owen]

Hmm... I don't have my reference manuals handy, but does exiting long mode necessitate reloading GS and FS? Because, if not, you could access 12GB of RAM by setting them correctly via the base MSRs, though in a rather cumbersome way (IIRC, you can't write to the base MSRs from !Long Mode)

Part of the reason Grub2 is becoming so complex is because it's intended to be usable as part of that OpenBoot mess...

[tom9876543]

But why would you even want to do something like that? Unreal mode is only ever used in bootloaders for convenience of using the BIOS, but I'm assuming no kernel will ever exceed 4 GB in size (or at least I hope: it seems like a monolithic kernel that big would collapse somehow).

I believe VESA requires the unreal mode hack to directly access the linear framebuffer in the 32bit address space. So what happens when there are 64bit PCI devices?

Also the BIOS in SMM mode may want to save the entire physical RAM to the hard drive. What happens when there is more than 4GBs? I guess all BIOS now have to temorarily jump into Long Mode on newer computers to safely save ALL the RAM. My suggestion would have allowed the BIOS to be 100% real mode code, and still access all physical RAM.

I have never owned a 64bit CPU (still stuck on a Duron 1200). In the memory map, is there a "memory hole" just below 4GB so the 32 bit PCI devices can be memory mapped? What happens to the RAM that should exist where the PCI devices are memory mapped - is it lost? How does it work?

Anyway, I think everyone agrees the x86 has been hack design on top of hack design on top of hack design. This is all theoretical.

[Love4Boobies]

I believe VESA requires the unreal mode hack to directly access the linear framebuffer in the 32bit address space. So what happens when there are 64bit PCI devices?

VESA does not require unreal mode for anything. There are several ways to use linear framebuffer (as opposed to bank switching) - memory mapping with DOS extenders is one example of a technique used in the past that is consistent with real mode. Although unreal mode would work, the best way is probably to use the protected mode interface that was added in VBE 3.0. Not all video cards support this, unfortunately. VESA does not work in 64-bit mode (unless emulated).

Also the BIOS in SMM mode may want to save the entire physical RAM to the hard drive. What happens when there is more than 4GBs? I guess all BIOS now have to temorarily jump into Long Mode on newer computers to safely save ALL the RAM. My suggestion would have allowed the BIOS to be 100% real mode code, and still access all physical RAM.

BIOSes (and firmware in general) would not attempt this due to several reasons:

• It'd waste a lot of time.
• The firmware would need to interpret file systems.
• It would waste disk space.
• Most importantly, there's no good reason the BIOS would ever want to do this.

In the memory map, is there a "memory hole" just below 4GB so the 32 bit PCI devices can be memory mapped? What happens to the RAM that should exist where the PCI devices are memory mapped - is it lost? How does it work?

Yes, PCI devices take up RAM below the 4 GiB mark. Your friend E820h will tell you exactly what the hole looks like.

Anyway, I think everyone agrees the x86 has been hack design on top of hack design on top of hack design. This is all theoretical.

More or less. x86 specifically refers to IA-32-compatible CPUs. x86-64, although being backward compatible with x86 drops most of the useless mumbo-jumbo since long mode is not a hack on top of protected mode, rather a redesigned operating mode.

[jal]

So what happens when there are 64bit PCI devices?

PCI and PCI-E have a 32-bit bus, AFAIK. Don't know about PCI-X.


JAL

[Love4Boobies]

So what happens when there are 64bit PCI devices?

PCI and PCI-E have a 32-bit bus, AFAIK. Don't know about PCI-X.

Not really. 64-bit support is defined in the PCI specification (although optional).

[jal]

Not really. 64-bit support is defined in the PCI specification (although optional).

As far as I understand the Wikipedia article, 64-bit support is about a 64-bit datapath, not about 64-bit addressing.


JAL

[Brendan]

Hi,

@tom9876543: Some AMD CPUs have an MSR that allows you to disable the "32-bit address wrap". This means that in protected mode you can have a segment where the base address is 0xFFFFFFFF and the limit is 4 GiB, and you could use it to access addresses from 0x0FFFFFFFF to 0x1FFFFFFFE. That means you could access 4 GiB with one segment and almost 4 GiB with a second segment, and end up with almost 8 GiB (actually one byte less than 8 GiB). I see no reason why this wouldn't also work in unreal mode. However, it's "CPU dependant" (it'd only work on some AMD CPUs). This is the only thing I'm aware of that comes slightly close to "64-bit unreal mode".

Not really. 64-bit support is defined in the PCI specification (although optional).

As far as I understand the Wikipedia article, 64-bit support is about a 64-bit datapath, not about 64-bit addressing.

64-bit PCI is for both 64-bit addressing and 64-bit data.


Cheers,

Brendan