OSDev.org

Combuster wrote:

a minimal V86 setup with a fictive timer int.

I rest my case.

A fictive timer is pretty easy to fix. In V86 mode, it can be done with a separate thread either updating the the timer tic location directly, or issuing the V86 handler for int 8.

In real mode, you just disable all interrupts except the PIT interrupt, possibly reprogram the APIC and PIT, and then it should work just as well as the minimal V86 handler. The problem would be possibly lost interrupts. Therefore, using V86 mode is preferable, at least if the switch should be done under normal operation (as in RDOS).

Brendan wrote: So your OS is under heavy load, with IRQs (from ethernet, serial, disk, timers, etc) and IPIs (from multi-CPU TLB shootdown) flying all over the place; and you disable IRQs and call the BIOS function to switch video modes; hoping that the video BIOS doesn't do the right thing and enable IRQs, and also hoping that the massive increase in IRQ latency this causes (if the video BIOS does the wrong thing) won't cause lost IRQs, lost packets, etc?

Why would it disable IRQs? The IRQs that happens in V86 mode are reflected into protected mode, and served by the usual handlers. The V86 video mode switch code naturally is executed with interrupts enabled, and this is ensured by disallowing V86 from tampering with cli/sti. V86 mode has a virtual interrupt flag that only affects task-switching between threads in the same process. The switch procedure creates it's own process to make sure this is not an issue.

Brendan wrote: It's a lot more likely your code is extremely buggy, your OS is never under load when you switch video modes, and you don't switch video modes often; and you think it's OK because you've been lucky and/or your idea of acceptable quality is significantly lower than mine.

Not so. I can switch at any state, including during writes to video memory with no crashes or other bad things happening.

Hi,

rdos wrote:

Brendan wrote:So your OS is under heavy load, with IRQs (from ethernet, serial, disk, timers, etc) and IPIs (from multi-CPU TLB shootdown) flying all over the place; and you disable IRQs and call the BIOS function to switch video modes; hoping that the video BIOS doesn't do the right thing and enable IRQs, and also hoping that the massive increase in IRQ latency this causes (if the video BIOS does the wrong thing) won't cause lost IRQs, lost packets, etc?

Why would it disable IRQs? The IRQs that happens in V86 mode are reflected into protected mode, and served by the usual handlers. The V86 video mode switch code naturally is executed with interrupts enabled, and this is ensured by disallowing V86 from tampering with cli/sti. V86 mode has a virtual interrupt flag that only affects task-switching between V86 threads in the same process.

I think there's been some misunderstandings here. Everyone (including me) was only talking about real mode, and nobody (except you) was talking about virtual8086 mode (which is something very different). Virtual8086 mode is "safe" (unlike real mode, which is what we were talking about) as the OS is still in complete control of IRQs, etc.


Cheers,

Brendan

I certainly agree with all the problems with switching to real mode during normal operation, but that would be really stupid given that V86 mode was constructed in order to not have these problems. OTOH, if it is possible to write bimodal protected mode / long mode interrupt handlers, I'm pretty sure it would be possible to create real mode IRQ-handlers as well which would handle interrupts from real mode, but it would be rather pointless when V86 mode exists.

It's real mode having everything to do with the BIOS. It'll be catching all the interrupts again even while the video card itself is not directly responsible for them.

Well, there is no need for it to do that. All handlers can be set as dummy functions that don't do more than necessary.

So your OS is under heavy load, with IRQs (from ethernet, serial, disk, timers, etc) and IPIs (from multi-CPU TLB shootdown) flying all over the place; and you disable IRQs and call the BIOS function to switch video modes; hoping that the video BIOS doesn't do the right thing and enable IRQs, and also hoping that the massive increase in IRQ latency this causes (if the video BIOS does the wrong thing) won't cause lost IRQs, lost packets, etc?

As for handling missed interrupts, I just keep a flag for each interrupt that arrives while in real mode. The corresponding handlers are then executed as soon as the real mode call returns.

A non-realtime operating system should generally be able to handle this kind of situation. If the ethernet receive buffer overflows, no harm is done. Network protocols are designed around the assumption that packet losses may occur at any time. And if IPIs break, you have no one to thank but yourself.