x86_64 port and BSP (GSoC 2018)

[Chris Johns]

On 26/03/2018 14:49, Amaan Cheval wrote:
> 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?

Yes as iPXE and others.

> 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.

I was thinking about as a point to remember. If it comes for free why not keep it.

> 
> 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)

This seems normal for SMP.

> - 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)

OK, this is what I saw and I went that is too much to do in a few hours so moved
on. :)

> - 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).

We found with the newer BIOSs with UEFI some interrupts are mapped above the
last slave PIC IRQ. It is just looking practically at the problem.

> 
>>> 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

It is not key. A BSP framework we can easily add this is.

> 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?
> 

It seems fine. My questions and concerns are about understanding expectations.

Chris