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

Thu Aug 9 12:43:15 UTC 2018

Addition to status: it doesn't seem like the RTEMS Interrupt's call to
_Thread_Dispatch functions either - ticker.exe has outputs like the
following (yeah, the counter is running too quickly right now):

*** BEGIN OF TEST CLOCK TICK ***
*** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
*** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
TA1  - rtems_clock_get_tod - 11:34:12   05/12/1990
TA2  - rtems_clock_get_tod - 11:34:12   05/12/1990
TA3  - rtems_clock_get_tod - 11:34:12   05/12/1990

(And then the _Thread_Idle_body is never preempted due to the
interrupt dispatching a new thread - not sure if it just thinks it's
"too late" to even bother or if simply never even tries. I'll keep
investigating.)

On Thu, Aug 9, 2018 at 6:03 PM, Amaan Cheval <amaan.cheval at gmail.com> wrote:
> Hi everyone!
>
> Good news! The APIC timer _does_ work now (after implementing 1GiB
> pages)! I see Clock_isr_ticks increasing steadily, though I don't have
> tc_get_timecount implemented yet - I've yet to figure out the
> specifics of the clock driver (how
> rtems_configuration_get_microseconds_per_tick influences the
> counter_ticks, specifically).
>
> I suspect we'll barely just make ticker.exe work by EOD tomorrow,
> leaving just the weekend for me to clean the patches up and Monday to
> actually merge them.
>
> Would someone be willing to have a meeting on Hangouts (or whatever)
> with me to speed up the process of (1) upstreaming my patches and (2)
> checking that my "work package" looks good enough at any convenient
> time on Monday?
>
> (I'm a bit busy on Monday, so I'd really prefer to have this whole
> thing done by EOD Monday for me.)
>
> On Thu, Aug 9, 2018 at 7:03 AM, Gedare Bloom <gedare at rtems.org> wrote:
>> 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