I let kernel.img loaded and executed by the Grub, then in the kernel.img can I make a bios call such as int 0x13?
The Multiboot specification says that:In other words,the OS should be able to make BIOS calls and such after being loaded...
But when the kernel.img begin execute,the Grub has make the CPU switch to PM, so how can make a BIOS call in the kernel.img?
Thanks
Can I call the bios function in this case?
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Can I call the bios function in this case?
if you're in pmode, you cannot call int 13h. period.
what the Grub doc tells you is that Grub has not altered the preciousss BIOS data areas and such, so if you set up a vm86 monitor or turn back to real mode, you can invoke the BIOS ...
what the Grub doc tells you is that Grub has not altered the preciousss BIOS data areas and such, so if you set up a vm86 monitor or turn back to real mode, you can invoke the BIOS ...
-
aladdin
Re:Can I call the bios function in this case?
i've made my kernel as a first task , and now i want to call a vm86 task.
so what is the difference between a vm task and a vm monitor?
and when i want to switch to vmmode, i'll need to unload paging and other things in kernel or in the vm task ?
so what is the difference between a vm task and a vm monitor?
and when i want to switch to vmmode, i'll need to unload paging and other things in kernel or in the vm task ?
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Can I call the bios function in this case?
Okay, a bit of terminology ...
We usually talk about 'VM86Task' or 'vm task' to refer to the Intel TSS that is used to run code in VM86 mode. It is convenient to have it as a separate TSS as it's a bit easier to set up that way...
Everytime the vm task does something wrong (try to access priviledged instructions, I/O ports, interrupts, etc.) it triggers a general protection fault exception (which can, depending on how you set up the GPF descriptor, be handled by the same TSS in pmode or by another TSS).
The 'vm86 monitor' is the protected-mode software that receives the GPF from the VM task and applies the 'correction' to the virtual mode state so that the operation is 'faked' (it could for instance redirect the CS:IP pair according to the values it reads in the realmode interrupt table).
There are pentium tricks that allows the VM task to invoke VM monitor less often, for instance by enabling virtual interrupts (CLI/STI will affect a special bit but won't block hardware interrupts targetted at protected mode), software interrupts redirection (letting the processor know that INT 13h should be interpreted as in real mode rather than throwing a GPF) or defining an IO protection map ...
We usually talk about 'VM86Task' or 'vm task' to refer to the Intel TSS that is used to run code in VM86 mode. It is convenient to have it as a separate TSS as it's a bit easier to set up that way...
Everytime the vm task does something wrong (try to access priviledged instructions, I/O ports, interrupts, etc.) it triggers a general protection fault exception (which can, depending on how you set up the GPF descriptor, be handled by the same TSS in pmode or by another TSS).
The 'vm86 monitor' is the protected-mode software that receives the GPF from the VM task and applies the 'correction' to the virtual mode state so that the operation is 'faked' (it could for instance redirect the CS:IP pair according to the values it reads in the realmode interrupt table).
There are pentium tricks that allows the VM task to invoke VM monitor less often, for instance by enabling virtual interrupts (CLI/STI will affect a special bit but won't block hardware interrupts targetted at protected mode), software interrupts redirection (letting the processor know that INT 13h should be interpreted as in real mode rather than throwing a GPF) or defining an IO protection map ...