OSDev.org

APIC INIT self-ipi is not sending the "processor" in a boot-loop, a lot of code I have written relies on obscure msrs and cpuid codes (ACPI is scary and ACPICA doesn't fit my threading model), can someone share some experiences and what to expect?

forgetme11 wrote: ↑Tue Dec 10, 2024 7:35 pmAPIC INIT self-ipi is not sending the "processor" in a boot-loop,

Are you expecting a boot loop? Most x86 CPUs should halt when they receive an INIT IPI, regardless of source. Only ancient CPUs (486 and early Pentium) reboot.

forgetme11 wrote: ↑Tue Dec 10, 2024 7:35 pma lot of code I have written relies on obscure msrs and cpuid codes

Which ones? QEMU is open source, you can look at its code to see what it supports. (Some of it also depends on the hypervisor, if you're using one.)

forgetme11 wrote: ↑Tue Dec 10, 2024 7:35 pm(ACPI is scary and ACPICA doesn't fit my threading model)

How about uACPI or LAI?

forgetme11 wrote: ↑Tue Dec 10, 2024 7:35 pmcan someone share some experiences and what to expect?

QEMU aims to run software, not accurately emulate hardware. If you're doing something that's too different from what major OSes do, it probably won't work in QEMU. (Heck, even plain old x86 segmentation doesn't work in QEMU.)

Octocontrabass wrote: ↑Tue Dec 10, 2024 11:26 pm(Heck, even plain old x86 segmentation doesn't work in QEMU.)

Oh did they break it? That would explain why I can't run MS-DOS or FreeDOS in QEMU any more, where I did years ago. Not that it ever worked well.

eekee wrote: ↑Wed Dec 11, 2024 4:25 am

Octocontrabass wrote: ↑Tue Dec 10, 2024 11:26 pm(Heck, even plain old x86 segmentation doesn't work in QEMU.)

Oh did they break it? That would explain why I can't run MS-DOS or FreeDOS in QEMU any more, where I did years ago. Not that it ever worked well.

If they have not broken more of the code, it was my impression that limit checking was not done, but that descriptor loads and bases still work. I could be wrong though.

eekee wrote: ↑Wed Dec 11, 2024 4:25 am

Octocontrabass wrote: ↑Tue Dec 10, 2024 11:26 pm(Heck, even plain old x86 segmentation doesn't work in QEMU.)

Oh did they break it? That would explain why I can't run MS-DOS or FreeDOS in QEMU any more, where I did years ago. Not that it ever worked well.

Just this minute ran a MS-DOS/Win3.11 disk image in whatever version of QEMU is in Ubuntu 24.04, and it ran fine. If they didn't do the segment limits properly, then who cares? DOS/Windows of the era was insecure anyway with little in the way of address space isolation.

And Program Manager - man, what were they smoking?

forgetme11 wrote: ↑Tue Dec 10, 2024 7:35 pm APIC INIT self-ipi is not sending the "processor" in a boot-loop, a lot of code I have written relies on obscure msrs and cpuid codes (ACPI is scary and ACPICA doesn't fit my threading model), can someone share some experiences and what to expect?

APIC INIT ICR cannot be delivered to self. It can be delivered only to another CPU/core/thread. If you wish to deliver it to self, you should create a task for another CPU/core/thread which sends the INIT to the target.
325384-083.pdf, 325384-084.pdf, 325384-085.pdf (and newer versions in the future)
table 11-4 valid combinations of Local APIC ICR
No shorthand - valid - INIT
All excluding self - valid - INIT
Self - invalid, note 5 - Lowest Priority, NMI, INIT, SMI, Start-Up
All including self - invalid, note 5 - Lowest Priority, NMI, INIT, SMI, Start-Up
note 5 - The behavior of the APIC is undefined.

I care about limit checking. If QEMU doesn't do proper limit checking then debugging on real hardware would be better since it does this properly (at least currently). It's a bit like ignoring page attributes, but I suspect QEMU does this properly.

rdos wrote: ↑Sat Dec 14, 2024 3:11 am I care about limit checking. If QEMU doesn't do proper limit checking then debugging on real hardware would be better since it does this properly (at least currently). It's a bit like ignoring page attributes, but I suspect QEMU does this properly.

And how would you go about debugging an OS on real hardware? GDB over serial line? Or do you use a JTAG header?

nullplan wrote: ↑Sat Dec 14, 2024 4:20 am

rdos wrote: ↑Sat Dec 14, 2024 3:11 am I care about limit checking. If QEMU doesn't do proper limit checking then debugging on real hardware would be better since it does this properly (at least currently). It's a bit like ignoring page attributes, but I suspect QEMU does this properly.

And how would you go about debugging an OS on real hardware? GDB over serial line? Or do you use a JTAG header?

I have my own emulator that handles segmentation correctly. It also handles the TLB the same way as real hardware does.

Still, I seldom need to use the emulator nowadays, since I have built-in tools that work on real hardware.

One is the "crash debugger", which contains an isolated environment that fatal errors in the OS can transfer to. The core state will be shown on the display, and with a PS/2 keyboard it's possible to inspect other core states and memory. It's also possible to execute code by singlestepping. Errors that are linked to the crash debugger are faults in IRQs or the scheduler. Kernel stack overflows also go here. It's possible to plant "CrashGates" at most positions in OS initialization code to debug hardware-specific issues. You cannot do that with QEMU.

I also have a kernel debugger that runs in it's own process. Using it, I can debug device driver code by planting breakpoints, or examine reasons for faults in kernel.

The application debugger can trace into kernel, which is the preferred way to debug device-driver code.

For somebody wanting to use QEMU to debug boot-code, not handling segmentation properly might lead to code that works with QEMU but then not working on real hardware. Not handling descriptor caches or TLB caches in a proper manner can lead to similar issues with code passing QEMU but then that doesn't work on real hardware. If I want to use an emulator, I want it to mirror hardware as closely as possible, even if that causes slower execution, and I would not want to stay on QEMU once the boot code and basic OS initialization works properly. At that time, tools for debugging on real hardware should be implemented and linked to exceptions.

rdos wrote: ↑Wed Dec 11, 2024 12:25 pm

eekee wrote: ↑Wed Dec 11, 2024 4:25 am

Octocontrabass wrote: ↑Tue Dec 10, 2024 11:26 pm(Heck, even plain old x86 segmentation doesn't work in QEMU.)

Oh did they break it? That would explain why I can't run MS-DOS or FreeDOS in QEMU any more, where I did years ago. Not that it ever worked well.

If they have not broken more of the code, it was my impression that limit checking was not done, but that descriptor loads and bases still work. I could be wrong though.

I have an admission to make: I was expecting more from DOS on my more recent tests than in the past. I was unwilling to run it without the 4DOS shell, and it's 4DOS which won't run in QEMU. Sorry for the noise.

I guess I have one more reason not to try to build an OS with segmentation. QEMU doesn't emulate it properly and I don't want to spend time on developing tooling to rdos's level. Not unless I get rdos and use its emulator. But I'm going for ARMv7 anyway. I've just got myself a Nintendo DS; there's a good homebrew scene making games and apps for 'bare metal' because that's normal for the DS. The "no$gba" emulator has debugging support.

In the past, RDOS has failed to run on most emulators, but a guy I know apparently managed to boot it on QEMU. RDOS is not dependent on limit checks, but since this is a protection mechanism, buggy code could simply pass on QEMU and overwrite stuff without any notice of what went wrong.