FFI callback for interrupts in Raspberry

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

FFI callback for interrupts in Raspberry

Denis Kudriashov
 
Hi.

I am experimenting with interrupt callbacks on Rasperry. I am using WiringPi library which allows to set the function which should be called when value of particular pin is changed.

But instead of callback execution I got following message in the console:

Warning; callback failed to own the VM


So VM is not crashed. But every interrupt produces such message.

Is it related to the fact that callback is triggered from the thread different from VM? (I not sure about such detail, just guessing)

Best regards
Denis
Reply | Threaded
Open this post in threaded view
|

Re: FFI callback for interrupts in Raspberry

Eliot Miranda-2
 
Hi Denis,


On Feb 19, 2018, at 6:35 AM, Denis Kudriashov <[hidden email]> wrote:

Hi.

I am experimenting with interrupt callbacks on Rasperry. I am using WiringPi library which allows to set the function which should be called when value of particular pin is changed.

But instead of callback execution I got following message in the console:

Warning; callback failed to own the VM


So VM is not crashed. But every interrupt produces such message.

Is it related to the fact that callback is triggered from the thread different from VM? (I not sure about such detail, just guessing)

Indeed it is.  You would need to either
- arrange that interrupts are delivered on the VM thread, e.g. by responding to the interrupt on the foreign thread by queueing the information, and using the external semaphore support to inform the image of the interrupt
- help us finish the threaded FFI so that the callback can be received from the foreign thread
- find out how a SqueakNOS VM handles receiving an interrupt at any time, or specific times (IIRC the Digitalk VM required the image to execute an enableInterrupts and a disableInterrupts bytecode around code that was executed when the VM is used n a state to take interrupts.

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?


Denis, can you describe the callbacks in more detail?  What is their favorite nation? Must they be responded to immediately? 


Best regards
Denis
Reply | Threaded
Open this post in threaded view
|

Re: FFI callback for interrupts in Raspberry

Denis Kudriashov
 
Hi Eliot.

2018-02-19 16:20 GMT+01:00 Eliot Miranda <[hidden email]>:
 
Hi Denis,


On Feb 19, 2018, at 6:35 AM, Denis Kudriashov <[hidden email]> wrote:

Hi.

I am experimenting with interrupt callbacks on Rasperry. I am using WiringPi library which allows to set the function which should be called when value of particular pin is changed.

But instead of callback execution I got following message in the console:

Warning; callback failed to own the VM


So VM is not crashed. But every interrupt produces such message.

Is it related to the fact that callback is triggered from the thread different from VM? (I not sure about such detail, just guessing)

Indeed it is.  You would need to either

At least VM do not crash. This is nice. 
 
- arrange that interrupts are delivered on the VM thread, e.g. by responding to the interrupt on the foreign thread by queueing the information, and using the external semaphore support to inform the image of the interrupt
- help us finish the threaded FFI so that the callback can be received from the foreign thread
- find out how a SqueakNOS VM handles receiving an interrupt at any time, or specific times (IIRC the Digitalk VM required the image to execute an enableInterrupts and a disableInterrupts bytecode around code that was executed when the VM is used n a state to take interrupts.

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?


Denis, can you describe the callbacks in more detail?  What is their favorite nation? Must they be responded to immediately? 

Signature is very simple:

int wiringPiISR (int pin, int edgeType,  void (*function)(void)) ;

I just checked how VM works in that case. It is not critical. Normally I just poll pin value.
 


Best regards
Denis


Reply | Threaded
Open this post in threaded view
|

Re: FFI callback for interrupts in Raspberry

philippeback
In reply to this post by Eliot Miranda-2
 
Eliot,

Would you mind explain a bit how the external semaphore thing works?

TIA
Phil

On Mon, Feb 19, 2018 at 4:20 PM, Eliot Miranda <[hidden email]> wrote:
 
Hi Denis,


On Feb 19, 2018, at 6:35 AM, Denis Kudriashov <[hidden email]> wrote:

Hi.

I am experimenting with interrupt callbacks on Rasperry. I am using WiringPi library which allows to set the function which should be called when value of particular pin is changed.

But instead of callback execution I got following message in the console:

Warning; callback failed to own the VM


So VM is not crashed. But every interrupt produces such message.

Is it related to the fact that callback is triggered from the thread different from VM? (I not sure about such detail, just guessing)

Indeed it is.  You would need to either
- arrange that interrupts are delivered on the VM thread, e.g. by responding to the interrupt on the foreign thread by queueing the information, and using the external semaphore support to inform the image of the interrupt
- help us finish the threaded FFI so that the callback can be received from the foreign thread
- find out how a SqueakNOS VM handles receiving an interrupt at any time, or specific times (IIRC the Digitalk VM required the image to execute an enableInterrupts and a disableInterrupts bytecode around code that was executed when the VM is used n a state to take interrupts.

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?


Denis, can you describe the callbacks in more detail?  What is their favorite nation? Must they be responded to immediately? 


Best regards
Denis


Reply | Threaded
Open this post in threaded view
|

SqueakNOS interrupts (was: FFI callback for interrupts in Raspberry)

Jecel Assumpcao Jr
In reply to this post by Eliot Miranda-2
 
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)
Reply | Threaded
Open this post in threaded view
|

Re: SqueakNOS interrupts (was: FFI callback for interrupts in Raspberry)

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

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.



On Mon, Feb 19, 2018 at 5:58 PM, Jecel Assumpcao Jr. <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: SqueakNOS interrupts (was: FFI callback for interrupts in Raspberry)

Eliot Miranda-2
 
Hi Javier,

On Tue, Feb 20, 2018 at 2:04 PM, Javier Pimás <[hidden email]> 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?
 
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.

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.




On Mon, Feb 19, 2018 at 5:58 PM, Jecel Assumpcao Jr. <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: SqueakNOS interrupts (was: FFI callback for interrupts in Raspberry)

melkyades
 


On Tue, Feb 20, 2018 at 11:47 PM, Eliot Miranda <[hidden email]> wrote:
 
Hi Javier,

On Tue, Feb 20, 2018 at 2:04 PM, Javier Pimás <[hidden email]> 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. <[hidden email]> 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