Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ap bringup util #343

Open
devsnek opened this issue Feb 12, 2023 · 2 comments
Open

ap bringup util #343

devsnek opened this issue Feb 12, 2023 · 2 comments

Comments

@devsnek
Copy link
Contributor

devsnek commented Feb 12, 2023

I'm using the new bootloader+bootloader_api for my OS (huge fan, love how easy it is to use!), and currently banging my head on SMP. I was thinking a nice feature to have would be a util for bringing up application processors, using all of the existing work/code that's already in the bootloader for the boot processor. I don't know exactly what such a util api would look like... maybe each AP uses the same entrypoint but there's info in BootInfo to differentiate?

@Freax13
Copy link
Member

Freax13 commented Feb 12, 2023

Related to #74

@jasoncouture
Copy link
Contributor

jasoncouture commented Mar 5, 2023

I, personally, don't think this is a good idea.

Here's why:

The bootloader already has a lot to do, with limited support and system resources (Especially in the case of bios). There are also different gotchas with various hardware iterations stretching back to the initial MP spec by intel. (IE: It's hard to get right across a variety of hardware). Beyond that, it requires reading and parsing the ACPI tables, and setting up the APIC to do IPI. Could it be done? Yes. But it would be less of a bootloader, and more of a kernel. It's also more information the kernel needs to take into account, how IPI was setup as an example.

Perhaps a better way to go about this would be to provide a no_std library that made it easy to start CPUs instead, and people could drop that into their kernel. Similar things exist for ACPI, Serial, and a few more things.

And one more thought, each architechture has it's own method of doing SMP. ARM's process requires i2c communication to the other CPUs. Much different from INIT/SIPI on x86(_64) see docs here: https://developer.arm.com/documentation/102337/0000/Functional-description/System-Boot/Boot-flow-overview?lang=en
This makes it much harder to port the bootloader to other architectures, such as ARM and RISC-V, as you now need to implement SMP on for that hardware as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants