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

x86_64 SMP bringup #345

Open
3 of 5 tasks
hawkw opened this issue Oct 14, 2022 · 4 comments
Open
3 of 5 tasks

x86_64 SMP bringup #345

hawkw opened this issue Oct 14, 2022 · 4 comments
Labels
arch/x86_64 kind/enhancement New feature or request

Comments

@hawkw
Copy link
Owner

hawkw commented Oct 14, 2022

@hawkw
Copy link
Owner Author

hawkw commented Oct 14, 2022

cc @iximeow

@hawkw
Copy link
Owner Author

hawkw commented Oct 14, 2022

switching over to ioapic is probably kind of complicated; might have to rewrite some of our interrupt code, and idk if timer 1 works with ioapic...

@hawkw hawkw added kind/enhancement New feature or request arch/x86_64 labels Oct 14, 2022
hawkw added a commit that referenced this issue Oct 14, 2022
This commit starts on #345 by using the `acpi` crate to read information
from the ACPI tables related to SMP. It adds an `acpi::bringup_smp`
function in `arch::x86_64`, but this function doesn't *currently*
actually bring up application processors. Instead, it just reads data
from the ACPI tables and logs it as a way to check that we are, in fact,
able to find the information we need.

Additionally, I added a new `ArchInfo` struct that contains opaque
architecture-specific data from the bootloader's boot info. This is
passed into the `kernel_start` function, but the cross-platform kernel
code doesn't consume it --- instead, it's just provided so it can be
passed back into `arch_init` once we've done cross-platform setup stuff.
This felt better than sticking the RSDP addr in a global variable or
something...

This is a first step towards #345. Future commits will actually switch
to IOAPIC interrupt handling and then start the application processors.
hawkw added a commit that referenced this issue Oct 14, 2022
This commit starts on #345 by using the `acpi` crate to read information
from the ACPI tables related to SMP. It adds an `acpi::bringup_smp`
function in `arch::x86_64`, but this function doesn't *currently*
actually bring up application processors. Instead, it just reads data
from the ACPI tables and logs it as a way to check that we are, in fact,
able to find the information we need.

Additionally, I added a new `ArchInfo` struct that contains opaque
architecture-specific data from the bootloader's boot info. This is
passed into the `kernel_start` function, but the cross-platform kernel
code doesn't consume it --- instead, it's just provided so it can be
passed back into `arch_init` once we've done cross-platform setup stuff.
This felt better than sticking the RSDP addr in a global variable or
something...

This is a first step towards #345. Future commits will actually switch
to IOAPIC interrupt handling and then start the application processors.
hawkw added a commit that referenced this issue Oct 14, 2022
This commit starts on #345 by using the `acpi` crate to read information
from the ACPI tables related to SMP. It adds an `acpi::bringup_smp`
function in `arch::x86_64`, but this function doesn't *currently*
actually bring up application processors. Instead, it just reads data
from the ACPI tables and logs it as a way to check that we are, in fact,
able to find the information we need.

Additionally, I added a new `ArchInfo` struct that contains opaque
architecture-specific data from the bootloader's boot info. This is
passed into the `kernel_start` function, but the cross-platform kernel
code doesn't consume it --- instead, it's just provided so it can be
passed back into `arch_init` once we've done cross-platform setup stuff.
This felt better than sticking the RSDP addr in a global variable or
something...

This is a first step towards #345. Future commits will actually switch
to IOAPIC interrupt handling and then start the application processors.
@hawkw
Copy link
Owner Author

hawkw commented Oct 19, 2022

APIC interrupt handling in progress here: #351

@hawkw
Copy link
Owner Author

hawkw commented Oct 22, 2022

APIC interrupt handling (#351) works now!!! I think all we need to do now is draw the rest of the owl actually start the application processors!

hawkw added a commit that referenced this issue Oct 22, 2022
This branch adds support for APIC interrupt handling on x86_64 systems.
In order to support Survival MultiPlayer, we need to be able to handle
interrupts using the APIC rather than the PICs, because the APIC
interrupt model allows multiple CPU cores to handle interrupts.

This is part of the work towards SMP support (#345).

This is a large change to the `hal-x86_64` crate's `interrupt` module in
order to add types representing the `LocalApic` and `IoApic`, and to
change the interrupt controller abstraction to switch to handling
interrupts using APICs if the system has APICs. If APICs are not
detected, we continue to use the PICs, but cannot support SMP.

In addition, the kernel is updated to use the new HAL APIs.

Several smaller changes to other parts of mycelium have been factored
out from this PR to merge separately:

* b99fb81 refac(hal-x86_64): move `pit` and `tsc` into `time` (#356)
* 9994cd5 feat(hal-x86_64): add PIT driver (#355)
* 30431a9 fix(trace): weird indentation on new spans (#354)
* 91e97b7 feat(hal-x86_64): add `cpu::Msr` type for accessing MSRs
  (#353)

We'll probably want to make additional changes to the new interrupt code
in subsequent PRs, but this is enough to get mycelium to use the APICs,
and demonstrate that he `maitake` timer wheel still works using the
local APIC timer).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch/x86_64 kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant