Long Mode and INT 0x15/EAX=0xEC00

[TannerGooding]

Ok, so i've been working on my OS for a while now and have started to rewrite it but in 64-bit code. I decided to look at the linux source code to see if I was even remotely doing it right (Turns out I was). I happened across the part where the linux kernel calls "INT 0x15, where EAX = 0xEC00 and BX = 2". My code runs just fine without it, so I was wonder exactly what this peice of code does and what the drawbacks are if you don't implement it. It isn't documented here on the wiki, any of the other OSDev sites, or Ralph Brown's Interrupt List.

[gedd]

Corrrect me if i'm wrong, please.
Is the Long mode is not "64 bits Protected mode" ?
Protected Mode in wich you cannot call int ? and even VM86 mode (for long mode)?

[jal]

Corrrect me if i'm wrong, please.
Is the Long mode is not "64 bits Protected mode" ?
Protected Mode in wich you cannot call int ? and even VM86 mode (for long mode)?

The OP very clearly knows what he is doing, and ask a very straightforward question, to which you are not giving an answer. Don't treat him like a noob, and don't post irrelevant stuff. He is explicitly mentioning the Linux kernel does it!


JAL

[jal]

My code runs just fine without it, so I was wonder exactly what this peice of code does and what the drawbacks are if you don't implement it.

A quick Google (try it too, some day! :)) reveals this:

int 0x15, EAX=0xEC00, EBX=2 : tell BIOS that operating mode will be Long

So it seems it is a new BIOS call, which explains RB doesn't list it.

And here's another East Asian site's code:

#if defined(__x86_64__)
/*
* Declare that our target operating mode is long mode.
* Initialise 32-bit registers since some buggy BIOSes depend on it.
*/
movl $0xec00,%eax # declare target operating mode
movl $0x0002,%ebx # long mode
int $0x15
"You could do it slightly earlier by intercepting bios int 0x15 eax=0xec00 ebx=2. The kernel issues that to tell the BIOS it is 64bit. That will only work if the boot loader does not skip the real mode code."

Appearantly, the BIOS likes to know wheter a 64-bit OS is running.


JAL

[mos]

Have a look at this :-
http://www.asmlove.co.kr/wiki/wiki.php/ ... e_bootsect

[Brendan]

Hi,

I happened across the part where the linux kernel calls "INT 0x15, where EAX = 0xEC00 and BX = 2".

I tried to track down the real reason for Linux to call this function, wondering if some sort of specification mentions it, or if it's required for a specific BIOS, or anything like that.

I couldn't find anything of the sort, except for it being mentioned in the Linux source. I tried to track it all the way back to the original patch where it was added to "setup.S", and found this patch by Andi Kleen from "2003-07-10" (either July or October in 2003).

The part that I find the most annoying (and most interesting) is the comment at the top:

- Tell BIOS we run in long mode
(this is a nop currently, but will help with some future boxes)

From this, I can only assume that Andi Kleen made it up!

I don't think this BIOS function actually exists, or does anything (other than returning a "WTF?" error code, that is ignored by Linux).


Cheers,

Brendan

[Zenith]

Damn, I was just doing that and I got stuck somewhere in a changelog entry in 2007...

And so, there's a chunk of code in almost all the Linux systems in the world that always gets executed at boot (for x64 at least, though x86 kernels would still waste a function call), because some random guy just posted it there with some valid code and the patch made it through (the code was never questioned, and was actually "edited" a few times by other people to use a special reg struct and interrupt function for example). Yay.

[jal]

From this, I can only assume that Andi Kleen made it up!
I don't think this BIOS function actually exists, or does anything

On the other hand, it's from 2003, and the first Opterons are from 2003, so it is very well possible that he based it on some specs he got, but didn't have an actual box to test it.

Everyone with a 64-bit BIOS should test this call, to see if it does anything.


JAL

[Brynet-Inc]

I found this thread on a mailing list related to Xen by Mr.Kleen.

http://marc.info/?l=xen-devel&m=120229414327038&w=2

I cannot find any information about this interrupt, hooray for magic.

[frank]

Maybe it was reverse engineered from something that windows did. All I've heard is that it tells the BIOS not to touch registers it shouldn't. It could have something to do with SMM. Maybe some BIOSs reacted differently depending on the processor mode but couldn't figure out what mode the CPU is in.

Here something from http://cvs.opensolaris.org/source/xref/ ... md64/cpu.c

Code: Select all

/*
    270  * Issue 'Detect Target Operating Mode' callback to the BIOS
    271  */
    272 static int
    273 detect_target_operating_mode()
    274 {
    275 	struct int_pb ic = {0};
    276 	int ret, ah;
    277 
    278 	ic.ax = 0xec00;	/* Detect Target Operating Mode */
    279 	ic.bx = 0x03;		/* mixed mode target */
    280 
    281 	ret = bios_doint(0x15, &ic);
    282 
    283 	ah = ic.ax >> 8;
    284 	if (ah == 0x86 && (ret & PS_C) != 0) {
    285 		dprintf("[BIOS 'Detect Target Operating Mode' "
    286 		    "callback unsupported on this platform]\n");
    287 		return (1);	/* unsupported, ignore */
    288 	}
    289 
    290 	if (ah == 0x0 && (ret & PS_C) == 0) {
    291 		dprintf("[BIOS accepted mixed-mode target setting!]\n");
    292 		return (1);	/* told the bios what we're up to */
    293 	}
    294 
    295 	if (ah == 0 && ret & PS_C && !amd64_special_hw()) {
    296 		printf("fatal: BIOS reports this machine CANNOT run in mixed "
    297 		    "32/64-bit mode!\n");
    298 		return (0);
    299 	}
    300 
    301 	dprintf("warning: BIOS Detect Target Operating Mode callback "
    302 	    "confused.\n         %%ax = 0x%x, carry = %d\n", ic.ax,
    303 	    ret & PS_C ? 1 : 0);
    304 
    305 	return (1);
    306 }

[Brendan]

Hi,

Ok, the code from Solaris looked like something "official" was actually defined, so I did more searching. It turns out that "0xec00" is good for finding code, and "ec00h" is better for finding documentation...

This function is defined (and explained) in "BIOS and Kernel Developer's Guide for AMD Athlon 64 TM and AMD Opteron Processors TM".

Here's the relevant text:

12.21 Detect Target Operating Mode Callback

The operating system notifies the BIOS what the expected operating mode is with the Detect Target Operating Mode callback (INT 15, function EC00h). Based on the target operating mode, the BIOS can enable or disable mode specific performance and functional optimizations that are not visible to system software.

This callback does not change the operating mode; it only declares the target mode to the BIOS. It should be executed only once by the BSP before the first transition into long mode.

The default operating mode assumed by the BIOS is Legacy Mode Target Only. If this is not the target operating mode, system software must execute this callback to change it before transitioning to long mode for the first time. If the target operating mode is Legacy Mode Target Only, the callback does not need to be executed.

The Detect Target Operating Mode callback inputs are stored in the AX and BL registers. AX has a value of EC00h, selecting the Detect Target Operating Mode function. One of the following values in the BL register selects the operating mode:

• 01h — Legacy Mode Target Only. All enabled processors will operate in legacy mode only.
• 02h — Long Mode Target Only. All enabled processor will switch into long mode once.
• 03h — Mixed Mode Target. Processors may switch between legacy mode and long mode, or the preferred mode for system software is unknown. This value instructs the BIOS to use settings that are valid in all modes.
• All other values are reserved.

The Detect Target Operating Mode callback outputs are stored in the AH register and CF (carry flag in the EFLAGS register), and the values of other registers are not modified. The following output values are possible:

• AH = 00h and CF = 0, if the callback is implemented and the value in BL is supported.
• AH = 00h and CF = 1, if the callback is implemented and the value in BL is reserved. This indicates an error; the target operating mode is set to Legacy Mode Target Only.
• AH = 86h and CF = 1, if the callback is not supported.

My apologies to Andi!

Of course now I'm wondering what else is missing from Ralph Brown's Interrupt List - it hasn't been touched since the 16th of July 2000, and I'm wondering if Ralph has lost interest. It might be nice to strip out all the irrelevant interrupts (DOS, Windows, etc) from RBIL, then turn it into a wiki (AFAIK it's the only BIOS reference that's available online).


Cheers,

Brendan

[Love4Boobies]

Ahem.

No one made anything up, this is indeed a valid BIOS service: detect target operating mode callback (AX = EC00h, INT 15h). I am not really sure which BIOSes actually do implement this but I know that AMD suggests that it be implemented. This callback needs to be executed before switching to long mode for the first time. The new operating mode is passed in the BL register (01h for legacy, 02h for long mode, 03h for mixed mode - the BIOS uses universal settings).

It's probably related to SMM operation. One might also assume that AMD proposed this interrupt to provide the usual services for modes other than real mode. If so, it will probably never be used. For more information, see section 12.21 of this document.

EDIT: how come I didn't see the post above?!

[jal]

It might be a good idea to put this on the Wiki somewhere?


JAL

[Love4Boobies]

Might be a good idea to find out what this actually does first All we know is that it optimises the BIOS settings for long mode but we have no clue what this means. Wonder if stlw has any knowledge of this?

[jal]

Might be a good idea to find out what this actually does first :) All we know is that it optimises the BIOS settings for long mode but we have no clue what this means.

I firmly disagree. It is an official BIOS API, described in an official document (as far as official goes). You don't *need* to know what it does(1), you only need to know when and how to use it.

(1)And very probably, that depends heavily on the BIOS vendor.


JAL