Calling Real-mode interrupt idea....

[Ready4Dis]

While I was debating if I should put a v86 handler (for calling bios interrupts from pmode) into my OS, or just write everything without it (although, I was having issues with a vga driver without access to the bios interrupts), I came upon a great idea and was wondering if anybody has attempted it yet.  Simply put an entry in my GDT for 16-bit code/data at memory address 0h, that way, I can manully get the address of each 16-bit interrupt.  Would the iret in the 16-bit code return properly if it was called form a pmode interrupt (using a simple jump instruction).  Anyways, here's the idea:

Call a pmode interrupt
Interrupt would read in the ivt at 0h and translate it's address over to a pmode address (it'd be a real-mode address), then jump to this address, which would have a valid 16-bit code/data entry in the GDT (so it knows to run it as 16-bit code!).
Jump to the address listed, and let it do it's thing, when it hits the IRET function, it'd return directly back to the location before the pmode interrupt was called.

Do you think this would work, or would a lot of things be broken because the interrupt is expecting to be in real-mode?

[carbonBased]

Sorry, but you can't do that.

The bios is going to be accessing memory in a real mode segmented model, which you simply don't have in protected mode.  Not to mention the iret would not return properly, no.

You'd be best off writting a vm86 handler (they really aren't that hard to write).

Cheers,
Jeff

[Ready4Dis]

I don't know about that... since a vm86 handler doesn't use segmented memory model, it uses whatever method you have setup in your pmode OS (paging for example), so I do'nt really see the difference.  I am not sure how the iret in 16-bit or 32-bit is different, but I'd be interested in finding out .

[mindvnas]

> I am not sure how the iret in 16-bit or 32-bit is different,

iret wich returns from 16bit to 16bit has bytecode 0xCF
irets from 32bit to 32bit also have 0xCF, but the ones that go from 16bit to 32bit or vice versa have an opsize override (0x66) prefix, so it just wont work.

[carbonBased]

The irets are different, and vm86 tasks DO run in segmented memory.  At least what looks to be segmented memory from the applications perspective.  It's the handlers job to map memory for the vm86 task, through whatever means it has supplied, and it's the handler's job to perform any translations, if necessary... however, from the tasks perspective, it still uses 16-bit segment, offset pairs.

Cheers,
Jeff