This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

IA64 Kprobes on Instruction SLOT 1 issues/solution


>31. Anil: Publish description of problem and solution regarding ia64
>probes set on slot 1 of a bundle.

Hi All,
	On IA64 we have something called "Instruction Bundle" as shown
below, which consists of 3 instruction slots each of which is a 41 bits
in length plus 5 bits template making a bundle as 128 bits(i.e 16 Byte).
Out of three instruction slots, SLOT_0 and SLOT_2 falls with in the
naturally aligned 8 BYTE boundary, however instruction on SLOT_1 will
occupy some bits in the upper 8 byte boundary long and lower 8 byte
boundary long word.

bit 128                                                        bit 0
-------------------------------------------------------------
| slot 2         | slot 1       | slot 0       | Template |
| bit 87-127  | bit 46-86  | bit 05-45  | bit 0-4     |
| 41 bits       | 41 bits     | 41 bits     | 5 bits       |

-------------------------------------------------------------

When a probe needs to be register/unregistered we need to update/replace
these 41 bits of the instruction slot atomically. In case of slot_0 and
slot_2 which happens to fall on the naturally aligned 8 byte boundary,
we can update this instruction atomically, using 8 byte atomic
instruction. However for supporting register/unregister kprobes on
instruction slot_1 we may need two operations to update the instruction
on slot_1 and the behavior is unknown if some other processor see
partially updated data for instruction slot_1. Hence we at Intel took a
decision not to support Kprobes on Instruction slot 1. Though there was
a solution to support Kprobes on Instruction slot_1 by stopping all the
cpu's (stop_machine_run() call) and then update the instruction, we
decided this was a heavy weight operation and kprobes need to be a light
weight operation and not heavy weight.

Current solution:
---------------------------
	Fail Kprobes if register_kprobe() happens to be on slot 1 and
this patch has already made it into linus tree.
-------------------------------

Impact:
--------------------
Impact of Kprobes not supported on Instruction SLOT_1 to Systemtap work?
	Impact of this to systemtap work should be very minimal as all
function instructions begins on slot 0, so there are no issues to
support Jprobes and return_probes and 2/3 of the instructions for
Kprobes are covered.
------------------------------------------------------------------------
-


Future solution
-----------------------
How can this be addressed in future with out taking heavy weight
stop_machine_run()?
	Intel's next generation IA64 Processor code named Montecito
supports atomically updating 16 BYTES and at that time we can support
Kprobes on instruction slot 1 only for that processor type.
-------------------------------------------------------

I hope we all are clear about what the problem here is and its impact to
systemtap work and the current solution. If any one disagrees with any
of the above, please raise your voice :-)


Thanks,

-Anil Keshavamurthy
Sr. Software Engineer
Open Source Technology Center/SSG
Intel Corp.
(w) 503-712-4476


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]