[GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Gedare Bloom]

On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval <amaan.cheval at gmail.com> wrote:
> Status update: The code is at a point where the APIC timer _should_
> work, but doesn't (it never starts ticking away, so when calibrating
> with the PIT, and later starting the APIC timer to generate IRQs,
> pretty much nothing happens).
>
> I suspect the cause being the APIC base relocation not working (the
> APIC is located at 0xfee00000 in physical memory by default, and in
> the code we write to an MSR to relocate it, because the page-mapping
> scheme FreeBSD setup doesn't let us access such high physical memory -
> only the first 1GiB of physical memory).
>
> On QEMU, the MSR accepts our write for the relocation and happily
> spits it back out when read, but given the unresponsiveness of the
> APIC timer despite enabling all the right bits, I suspect it's just a
> "fake" in that regard (QEMU's "info lapic" doesn't reflect any of our
> changes to the APIC configuration either, supporting this theory).
> QEMU _does_ reflect changes to the APIC by other operating systems
> which don't relocate it, so I don't suspect its emulation being a
> problem.
>
> On VirtualBox, the MSR simply silently swallows the write, and upon a
> read, returns the original 0xfee00000 value again. This means that if
> we can't relocate it, we can't access it at the moment either.
>
> The only real way to work around this is to have a paging scheme that
> lets us access physical address 0xfee00000 - in that case, we could
> support page-faults and dynamically map pages in, _or_ have static
> pages that are absurdly large (such as 1GiB), letting the virtual
> address do the heavy-lifting in terms of finding the
> virtual-to-physical mapping.
>

I recommend a few static super pages to get it working. It is simple
and fits the prevailing RTEMS model.

> Either way, I think this issue this close to the deadline basically
> means the APIC timer won't be functional and make it upstream.
>
> I'll clean things up and send patches tomorrow for everything so far,
> including all the stub-code which will become usable once our paging
> scheme works fine.
>
> If anyone has any last-minute swooping ideas on how to save the APIC
> timer, let me know! (Interrupts aren't masked, and as far as I can
> tell, changing the "-cpu" flag on QEMU doesn't make a difference. I
> don't have any ideas as to what else the problem could be.)
>
> In my final report, I'll make sure I document what's remaining in
> clearer terms than I have in this email, so it's easier for other
> contributors to pick it up too, if any are interested.
>
> </rant>
>
> On Tue, Aug 7, 2018 at 6:03 AM, Chris Johns <chrisj at rtems.org> wrote:
>> On 07/08/2018 09:27, Joel Sherrill wrote:
>>> On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval <amaan.cheval at gmail.com
>>> <mailto:amaan.cheval at gmail.com>> wrote:
>>>
>>>     Thanks for all the help! I have a simple test using the RTEMS
>>>     interrupt manager working successfully (tested by calling
>>>     rtems_interrupt_handler_install for vector 0, and then triggering a
>>>     divide-by-0 exception).
>>>
>>> Yeah!
>>>
>>>     Could someone shed any light on why the i386 only hooks the first 17
>>>     vectors as "RTEMS interrupts"?
>>>
>>> You are making me feel very old especially since I have the real
>>> IBM manual in my office which corresponds to the answer.
>>
>> Grandchildren, grey hair or Sebastian posting he is feeling old do not make you
>> feel old? Interesting! ;) :)
>>
I feel old, too.

>>> It is dated Sept 1985. In fairness, I saved it from the garbage heap
>>> years later when someone was cleaning out their office. :)
>>
>> Ah the good old days before the internet and search engines!!
>>
>>> The x86 architecture is really vectored and the original i386
>>> port actually used simple direct vectoring since the first BSP wasn't
>>> a PC. Imagine that!  Another board using an i386 which didn't
>>> look like a PC at all.
>>>
>>> For better or worse, the PC/AT (286) and later used two i8259 PICs
>>> in a master and slave configuration. The slave PIC cascaded off the
>>> master PIC. This all fed into one CPU IRQ so many of the direct
>>> vectors were unused. The PIC arrangement is described here:
>>>
>>> https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)
>>>
>>>     Here's what I'm aiming to get done before the GSoC deadline:
>>>
>>>     - Remap PIC (masking/disabling the PIC doesn't stop it from generating
>>>     spurious interrupts (IRQ7), which would look like exceptions to us)
>>>     - Disable PIC
>>>     - Enable APIC (done already, but confirm it plays well with the recent
>>>     changes to the IDT)
>>>     - Enable the PIT timer and use it to calibrate the APIC timer
>>>     - Clock driver using the APIC timer - (1) generate interrupts on ticks
>>>     and (2) tc_get_timecount function which calculates total time passed
>>>     through calculating (number of IRQs occured * time_per_irq +
>>>     time_passed_since_last_irq (through tick counter))
>>>
>>>     This does seem a bit ambitious given how short we are on time - I'll
>>>     finish this up even after the deadline if need be.
>>>
>>>     What should our minimum deliverable be for this period? Should we try
>>>     to upstream the interrupt support before I finish the clock driver? (I
>>>     think we can have this discussion on Wednesday or so, since by then
>>>     I'll likely know how much progress on the clock driver remains.)
>>>
>>> We could but do you think it is likely to have major changes based
>>> on getting the tick working?
>>>
>>> Try to see what gets done and post what you can by the end of GSoC.
>>>
>>> Then we will all wait patiently for you to get it working if it isn't then.
>>
>> I think this BSP code in our repo is the best place for it to be worked on.
>>
>> Chris