[Vm-dev] SqueakNOS interrupts (was: FFI callback for interrupts in Raspberry)

[Javier Pimás]

On Tue, Feb 20, 2018 at 11:47 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Javier,
>
> On Tue, Feb 20, 2018 at 2:04 PM, Javier Pimás <elpochodelagente at gmail.com>
> wrote:
>
>>
>> That's a perfect description. The isr handler calls
>> signalSemaphoreWithIndex and
>> quietly returns. In the image there is one process waiting on each
>> interrupt (smalltalk)
>> semaphore, with the smalltalk handling code for that interrupt. Of
>> course, this only
>> works for external interrupts, and not for exceptions (normally when you
>> get a processor
>> exception while running smalltalk code it means something very wrong just
>> happened,
>> so you cannot just go back to it). IIRC for paging we used alienffi
>> callbacks, but there
>> is a trick, you have to know a bit about the code triggering the page
>> faults, in order to
>> assure that it is safe to reenter the vm.
>>
>
> Can you say more about page faults?  Can you handle these in Smalltalk?
>  (I would think one can't)  Do you instead want a dedicated page fault
> handler?
>

Yes! I think we showed it in the great Smalltalks conf at CdU almost a
decade ago. The limitation was to raise the #PF in a controlled way (in
that case, a primitive to read arbitrary memory position). When the
exception was raised, the native code handler saved the VM state (in a very
hacky way), and reentered through an alien callback. In smalltalk it was
possible to place a halt in the handler and debug everything normally. The
exception-causing code was left paused until the callback went back, moment
at which the VM state was "restored" (I can't remember the details, but I
guess it only made sense to restore a subset of the interpreter state).


>
>> Handling exceptions is a topic for research. But for that it is necessary
>> to rethink in which
>> situations exceptions could happen. For example, could a cogvm generate a
>> zero division
>> exception? If not, then a #DE might mean that the vm just crashed.
>>
>
> Well, for SqueakNOS I guess it makes sense that the VM should never
> generate an exception.  But if one has a Smalltalk system with an FFI then
> FFI calls might generate exceptions and it is /much/ nicer to catch the
> error and report it back, a bit like a primitive failure, rather than
> crashing the VM.  So I modified the VisualWorks VM to handle exceptions
> such as illegal instruction and bus violation and if these occurred during
> an FFI call (identified simply by setting and clearing a flag when in an
> FFI call) the handler arranged that the FFI call "failed" and the exception
> code was reported.
>

Yes, that would make sense here too. Remember that until now we havent done
any research in protection mechanisms under squeaknos, all the code runs in
ring 0, so there's no OS/user separation.


> This gets more complicated when the VM is threaded.  Here one still needs
> to set and reset the flag when an FFI call is in progress, because the
> threading on FFI calls works by the heartbeat thread noticing that the VM
> is in an FFI call and then starting up another thread to run the VM.  So
> the exception handler needs to check got both the "in FFI call" flag when
> on the current VM thread, and for occurring in some other thread.  And if
> the exception happens in some other thread and that thread is known to the
> VM and is in fact a thread that is currently doing an FFI call then again
> the exception can be collected and the FFI call can "fail" and answer the
> exception information.
>

We still have to determine how to implement the support for the heartbeat
thread at all in squeaknos, but yes, when that is done error checking
during threaded ffi seems complex but doable.


>
>>
>>
>> On Mon, Feb 19, 2018 at 5:58 PM, Jecel Assumpcao Jr. <jecel at merlintec.com
>> > wrote:
>>
>>>
>>> Eliot,
>>>
>>> > The thing I do not understand about SqueakNOS and responding to an
>>> interrupt
>>> > at an arbitrary time is how one expects to deal with handling an
>>> interrupt during
>>> > some sequence of instructions that is between suspension points, such
>>> as mid
>>> > way through a store check which is adding an object to the remembered
>>> set, or
>>> > mid way through a message lookup.  Does SqueakNOS actually use the
>>> > enable/disable interrupts approach?
>>>
>>> If I understood correctly, the only thing the VM does when it gets an
>>> interrupt from the 8259 chips is to signal a corresponding semaphore and
>>> immediately return to what it was doing. At some point in the future the
>>> code waiting for the semaphore gets scheduled and then run by the VM,
>>> but at that instant none of the problems you mention should happen. It
>>> is that code that is resposible for telling the 8259s that the interrupt
>>> has been handled so only then can it receive the next one.
>>>
>>> -- Jecel
>>>
>>> http://wiki.squeak.org/squeak/1762 (see "SqueakNOS IRQ Handling" in the
>>> middle of this page)
>>>
>>
>>
>>
>> --
>> Javier Pimás
>> Ciudad de Buenos Aires
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>


-- 
Javier Pimás
Ciudad de Buenos Aires
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180222/90e3702e/attachment-0001.html>