Drivers and virtual 8086 mode?

[lopidas]

I was reading trough osdev and I run to this thing:
First time i thought this:
Drivers gathers all requests compose them to one set of arguments passed to BIOS interrupt trough v8086. Two types 32-bit and 64-bit are needed on many systems because of change in instruction encoding and mapping to 64-bit word-length.
Than I got here http://wiki.osdev.org/Entering_Long_Mode_Directly
and looked at screen filling commands and thought this:
I need to know where drived hardware is placed in virtual memory instead of calling interrupt calls.

Which one is correct?
P.S.:I have feeling that both.

[Jezze]

I dont understand. Can you be more specific?

[greyOne]

I what.

I see virtual 8086 mode. And I see Long mode.
If you read this: X86-64, you'd know the former doesn't exist in the latter.

Two types 32-bit and 64-bit are needed on many systems because of change in instruction encoding and mapping to 64-bit word-length.

Is it further to New York than it is by bus? True or false: what was the bus driver's name?
I'm quite serious; what was that statement supposed to be?

I need to know where drived hardware is placed in virtual memory instead of calling interrupt calls.

I feel like this question lacks any sensibility,
So my response is simple:
'Drived hardware' goes inside your PC. Typically installed with a screw driver.

I think a proper understanding of the English language was a requirement somewhere.
Just a hunch.

[lopidas]

I will try to reformulate it
Best for me will be True/False, why false answer

1. I can access device/interrupt out of real mode by doing this switch to v8086.
2. It is not accessible from long mode.
3. I can access it by switch to 32-bit and than to v8086.
4. Drivers are of two types:
4. 1.gathering information, composing them and passing to v8086 interrupt
4. 2. calling known addresses of devices as here http://wiki.osdev.org/Entering_Long_Mode_Directly
comments about ; Blank out the screen to a blue color.

And of course what are other ways of doing hardware call?

[Gigasoft]

It appears that you are just putting together random words. This is a discussion website for operating system developers. That means highly experienced and skilled computer engineers. Not third world people who can't read or write. You want to become a computer programmer - first learn to read and write.

[Brendan]

Hi,

1. I can access device/interrupt out of real mode by doing this switch to v8086.

True, if you're in protected mode. False if you're in long mode.

2. It is not accessible from long mode.

True.

3. I can access it by switch to 32-bit and than to v8086.

False, switching to a 32-bit code while staying in long mode will not work. You'd have to switch to protected mode to use virtual8086.

4. Drivers are of two types:
4. 1.gathering information, composing them and passing to v8086 interrupt
4. 2. calling known addresses of devices as here

True (sort of).

And of course what are other ways of doing hardware call?

There are BIOS functions and UEFI functions. These exist so that an OS can be started (and do not exist for an OS to use after it is started). A real OS has its own drivers that access the hardware directly (e.g. using memory mapped IO, IRQs, IO ports, etc). If you lack the courage to write your own drivers, then you shouldn't be doing OS development to begin with.


Cheers,

Brendan

[lopidas]

Thanks for amazing answer.

[AbstractYouShudNow]

If you need BIOS interrupts (like setting video modes) under long mode, you're better off using an emulator

[rdos]

It is possible to use v86 mode in a long mode operating system provided you support switching between long mode and protected mode, which really only requires bimodal interrupt handlers.

But I think it is a real bad idea to use real mode drivers. About the only utility of v86 mode is to call VBE BIOS to switch video mode.

[chickendinner]

From what i can gather you want to access real mode bios interrupts from long mode. While this isn't recommended since you should be writing your own native long mode drivers, it's the only option for accessing the VESA BIOS code since very few modern computers support the protected mode BIOS interface.

If so you realistically have 2 options:

1. Switch modes

• Switch back to real mode and issue the interrupt.
• Switch back to 32bit protected mode and run a v86 task.
• If you're feeling particularly crazy you could even fire up an adjacent CPU core (that may or may not exist) and have that run the BIOS interrupt while its still in real mode.

2. Use x86emu an 8086 emulation library or similar.

Set its memory to be the first MB of physical memory, place an "int" instruction somewhere in the 640kb region of free memory and set the instruction pointer to point to it. Then start the execution. This will then execute the BIOS interrupt code inside the emulator while you're in long mode.

You need to modify the emulator so when it emulates an in or out instruction the CPU actually executes an in/out instruction, and when it returns back to the int instruction the emulator stops.

From my limited knowledge this is the approach Linux uses when it wants to execute VESA mode switches on systems that have an x86 VESA BIOS in memory but don't have x86 processors.

Having mode switches in your kernel messes with the organisation and structure of the entire thing. Your kernel will go through chunks of time without being able to serve IRQ's or run its scheduler making it clunky. With this approach you can keep your kernel code clean and elegant and just have a placeholder drivers that use the emulator library you can swap out when you write long mode alternatives. Its also a faster approach than switching modes since mode switches on a CPU are super expensive due to all the page invalidation and thousands of cycles it costs to actually switch, that along with the responsiveness lost when you can't service IRQ's or switch tasks makes this by far the best option IMHO.

There are a few pitfalls. For example some chipsets emulate USB keyboards and mouses as old PS/2 devices so the BIOS can work with them without a sophisticated USB stack. But sometimes as soon as you interface with the chipset directly or enter pmode this emulation is turned off breaking the interrupt code (So the operating system doesn't think it has 2 separate PS/2 and USB keyboards). Or if the BIOS interrupt tries to use any IRQ's itself instead of polling (it shouldn't, but BIOS's aren't known for being consistent) which would mean you'd need to hook up the old ISA IRQ's to interrupt the emulator, something as horrible as just switching modes. Or god forbid some of the interrupts that take 32bit arguments try to enter protected mode while in your emulator. But this shouldn't be a problem for simple tasks like VESA mode switches and basic IO on the vast majority of systems.

[rdos]

If so you realistically have 2 options:

1. Switch modes

• Switch back to real mode and issue the interrupt.
• Switch back to 32bit protected mode and run a v86 task.
• If you're feeling particularly crazy you could even fire up an adjacent CPU core (that may or may not exist) and have that run the BIOS interrupt while its still in real mode.

I don't find switching back to real mode realistic. First, it would require two mode-switches and a need to setup interrupt handlers that switches between real mode and long mode, which would get real bad. Second, a lot of the OS code related to interrupt handling would need to reside in the first 1MB of physical memory, as real mode also must turn-off paging.

Having mode switches in your kernel messes with the organisation and structure of the entire thing. Your kernel will go through chunks of time without being able to serve IRQ's or run its scheduler making it clunky. With this approach you can keep your kernel code clean and elegant and just have a placeholder drivers that use the emulator library you can swap out when you write long mode alternatives. Its also a faster approach than switching modes since mode switches on a CPU are super expensive due to all the page invalidation and thousands of cycles it costs to actually switch, that along with the responsiveness lost when you can't service IRQ's or switch tasks makes this by far the best option IMHO.

If you already have a 32-bit kernel, it would make most sense to use switching to protected mode as most of the code would run there anyway. For a new long mode kernel, the emulator approach would be the best.