As part of the s390x port I'm implementing soft interrupt handling and 
cross-CPU calls. The way System z does program generated interrupts is via the 
SVC instruction. This interruption cannot be masked so it will be processed 
despite what the PIL setting is. PIL is being done in software and depending on 
the level I will mask off I/O interrupts and/or external interrupts (which are 
what clocks and cross-system calls generate). 

For background System z has the following interrupt types:
- I/O (the device interrupting is identified as part of the information passed)
- External
- Machine check (damage notification or configuration change notification)
- Supervisor call (SVC  - i.e. soft interrupts)
- Program check (invalid operation, divide by zero, privileged operation, page 
fault etc.)

The Program Status Word (PSW) is the control register that holds the masks that 
enable you to mask external, I/O and machine check interruptions. In addition, 
it has control registers that allow you to mask specific external interruptions 
and 8 classes of I/O interruptions. Program check and SVC interrupts cannot be 
masked.

My questions are:

1. For cross-system calls System z uses the SIGP instruction which allows you 
to send signal to another CPU and pass it a 32-bit parameter (which makes the 
Sparc way of passing a function pointer and up to two arg pointers not 
possible). I'm interested in how x86 implements x-calls and how it achieves 
what Sparc is able to achieve.

2. For soft interrupts I can, in software, compare the PIL setting to see if I 
should process or defer the processing of the interrupt. If it's the latter, do 
either of the other architectures provide a mechanism for deferring the work 
that I could use as a model. I take it that Sparc is able to mask the interrupt 
from happening until it's ready which leaves x86 as a possible model. 

Neale
 
 
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to