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

[Amaan Cheval]

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.

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! ;) :)
>
>> 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