x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

Hi!

Thanks for your comments on the document, by the way. Regarding the
following comment:

> We should support multiboot as well for legacy X86 BIOSes. There are
headers about that can do this.

This is a great point - this way legacy BIOSes only need something like
GRUB (or a bootloader implementing the Multiboot spec) to boot RTEMS'
x86-64 port, right?

Do you think it's okay to lay this out as a bonus feature? It seems simple
enough, but I think the scope of the project as-is at the moment seems just
right, in that it leaves a little room for unexpected time-consuming
Heisen-bugs.

On Mon, Mar 26, 2018 at 4:08 AM Chris Johns <chrisj at rtems.org> wrote:

> On 20/03/2018 18:10, Amaan Cheval wrote:
> > On Tue, Mar 20, 2018 at 11:44 AM Chris Johns <chrisj at rtems.org> wrote:
> >> On 20/03/2018 16:21, Amaan Cheval wrote:
> >>> On Tue, Mar 20, 2018 at 8:23 AM Chris Johns <chrisj at rtems.org> wrote:
> >>>> On 19/03/2018 18:36, Amaan Cheval wrote:
> >>> (Assuming that by tables you meant the Local Vector Table, etc., and
not
> >>> the ACPI's MADT, which is relevant to SMP in that it contains a list
of
> >>> LAPICs, thereby letting us find how many cores are available.)
> >
> >> I was thinking about the SMP tables. SMP is not part of this work at
the
> > moment
> >> so what ever is needed in this area to make the BSP work. Is the Local
> > Vector
> >> Table included in the list of tables?
> >
> > Oh, did you mean the MP Table / ACPI MADT as mentioned in the 2nd bullet
> > here? (From volume 3 of Intel's IA32 and 64 manual.)
> > https://i.imgur.com/elZIlfy.png

> It has been a while since I looked at this. Is there a table for
interrupts and
> interrupts beyond the master/slave legacy PICs?

The way I understand it is:
- There are local APICs per core (making up a CPU)
- Local APICs have local events such as APIC timers, perf counters, I/O
devices, etc. - the Local Vector Table is used to configure each of these
local interrupt sources
- Multiple local APICs can talk to each other through the system/APIC bus
(model-specific) through Inter-Processor Interrupts
- The I/O APIC is connected to the system/APIC bus, and allows external
devices (including PCI) and system hardware to communicate with the local
APICs (individual CPUs on an SMP system)
- To use the I/O APIC, you need to parse either MP Tables or tables through
ACPI (determining how devices map to the I/O APIC's input pins, to tease
out where lines are being shared, and how interrupts may be redirected)
- The Interrupt Descriptor Table (IDT; protected mode) or Interrupt Vector
Table (IVT; real mode) are then used to actually call the ISR that was
registered (depending on specific configuration and the type of
interrupt/exception, of course)

I believe the distinction you're looking for is one about configuring more
than just the legacy master/slave PIC, which should be accomplished merely
by our use of the APIC (even if complete setup and interfacing with the I/O
APIC is not in the scope of this proposal, the project sets up future
improvements nicely).


> > One of those tables will need to be parsed to configure boot for SMP
> > systems correctly, yes. I thought you meant the tables that need to be
> > setup for the local APIC to be initialized and used correctly (which is
> > also necessary to be able to send Startup Inter-Proessor Interrupts
(SIPI)
> > for SMP boot to work).

> I think interrupts to access to various PCI devices beyond the slave PIC
is all
> we need for now.

Do you think of this as a key deliverable? To me, it was a bonus feature,
given that setting this up correctly is apparently a lot of work; see the
following forum post, for example:
https://forum.osdev.org/viewtopic.php?f=1&t=21745&start=0#p174219

Getting this to work correctly would also mean parsing MP tables, or
accessing tables through ACPI (which is also a bonus feature for the scope
of this GSoC proposal).

Does that sound okay?


> Chris