x86 SMP with cpus on different processor modes

[i4ki]

I explained my problem here: http://forum.osdev.org/viewtopic.php?f=1&t=30969

And now I'm sure it can work. This weekend I was studying how to parse the MP tables to get correct info from cores, when the code is ready I'll push it to repo with some docs.

My question is: Does anyone have interest in help creating an example of SMP (Symetric Multiprocessing)?

It's not a trivial problem and even the osdev.org miss a working example for that.

@CoolerVoid @m0nad @geyslan @c0defellas/osdev

[geyslan]

And now I'm sure it can work. This weekend I was studying how to parse the MP tables to get correct info from cores, when the code is ready I'll push it to repo with some docs.

Have you finished it?

My question is: Does anyone have interest in help creating an example of SMP (Symetric Multiprocessing)?

Sure I have. :smiley:

I would like to know which are your thoughts after the forum.osdev.org members cold water?

[chkhalt]

Hey guys, how are you doing? Has this issue made any progress?

About the question on osdev, I think is possible to do that. We could switch execution of kernel for a AP and return to real mode in BSP or even restarting the BSP sending INIT IPI to it. If you wanna use IPIs, may be necessary to set the warm-reset in BDA + CMOS offset 0F to use a startup trampoline, because some processors seems to start execution in reset vector (0xFFFFFFF0) as soon as they receive an INIT IPI (QEMU for example). Other processors, will enter in a "wait-for-sipi" state and jump to code present in the vector of SIPI-IPI. May be necessary to clear IA32_APIC_BASE.BSP (MSR 0x1B), as related in this forum (but I'm not sure about that, may be in specific cases):

https://software.intel.com/en-us/forums/intel-moderncode-for-parallel-architectures/topic/289483

It is important to note that, this approach should work only in Intel cpus because AMD seems to have a READ ONLY bit on their APIC_BASE.BSC (AMD64 Architecture Programmer’s Manual Volume 2: System Programming - 16.3.1 Local APIC Enable). Even so, to come back to real mode in BSP should work fine.

In my opinion, this is not the big problem. The problem comes with the need of have a kind of "isolated old fashion" core (or logical processor) that uses BIOS interruptions, try to interact with any kind of devices using I/O ports, and must be sync with the rest of system that has a pretty new abstraction layer (paged memory, device drivers, task switching, and so on...). Anyway, I think it is not new for you, since the guys of osdev have made good comments about that.

Anyway, if that idea is going to proceed, I wanna help. I like this kind of madness :D If the code is not successful, the knowledge will have ;)

Cheers

[i4ki]

@p4nthr0 Unfortunately, I ran out of time to continue the project :-( Nowadays I'm working on other kinds of stuff, but have time and energy to help someone that could lead this idea =)

About implementation, I think what you said makes sense but is a somewhat different use case.

I think there's a safe path to drive BSP into pmode, use IPI to initialize APs and go back the BSP into rmode whenever needed without requiring BSP restart because in my use case I only want the APs in pmode to address the entire RAM (no I/O port programming, paging, processes, etc in AP processors). If that's not the case, maybe it's too madness even for me hehe

If you wanna help, I think a good start should be a documented example of parsing MP tables (if you think MP still makes sense to use) to get processor's info. Even if you wanna try the advanced use case (BSP in rmode and full APs), this should be a good start that helps us and community =)

Thanks for your interest in helping :)

[i4ki]

oops, about my use case, the plan is here: https://github.com/tiago4orion/EnzOS/blob/master/plan.md#smp-bsp-in-rmode-and-ap-in-pmode

[chkhalt]

I only want the APs in pmode to address the entire RAM

Why not unreal mode? We could set B flag in segment hidden cache of all data segments, access entire RAM but continue using 16-bit code. Do you prefer to use 32-bit code for another specific reason, or is just the problem with memory access range?

[i4ki]

I started prototyping in unreal mode, but soon get rid after reading comments on osdev.org regarding processor going back to real mode after invoking some BIOS functions. Paraphrasing the link: Some BIOS routines updates the ES segment register, then the processor updates the descriptor cache and put the OS in real mode 16-bit again.

https://github.com/tiago4orion/EnzOS/blob/master/plan.md#32-bit-real-mode---aka-unreal-mode

[chkhalt]

Hummm, that's a interesting point! As I never coded nothing but "broadcast logical processors and choose one using a kind of lock arbitration", I'm learning about ACPI tables and how find APIC IDs from there. I hope to come back here with some PoC code in a few days (or weeks rsrsrs).

[chkhalt]

Hey guys!

I'm back with a simple exemple of parsing ACPI Tables to find LAPIC IDs. https://github.com/p4nthr0/draft-x86-acpi-lapic

For now, I have many questions in my mind, and the code is not as good as it could be. Anyway, I think I can start to use that informations to do a very simple core management (or logical processor management).

The main reference was chapter 5 of: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf