Firstly, let me remind that my understanding of low lovel hardware details
is very limited.
On 05/06, Denys Vlasenko wrote:
>
> Oleg, can you clear for me the following -
>
> If the probed instruction triggers an "illegal insn" or "privileged insn"
> CPU exception - are we completely fine?
Yes I
On 05/05/2014 09:41 PM, Oleg Nesterov wrote:
> On 05/05, Denys Vlasenko wrote:
>>
>> + * Opcodes we'll probably never support:
>> + * 6c-6f - ins,outs. SEGVs if used in userspace
>> + * e4-e7 - in,out imm. SEGVs if used in userspace
>> + * ec-ef - in,out acc. SEGVs if used in userspace
>
> Well.
On 05/06/2014 12:32 AM, Jim Keniston wrote:
> All of the following is FYI.
>
> The good-instruction tables date back 2006-2007. Back then, the
> philosophy was to disallow any questionable opcodes, and add them back
> into the "good" tables only when a need was demonstrated (i.e., somebody
>
On 05/06/2014 12:32 AM, Jim Keniston wrote:
All of the following is FYI.
The good-instruction tables date back 2006-2007. Back then, the
philosophy was to disallow any questionable opcodes, and add them back
into the good tables only when a need was demonstrated (i.e., somebody
needed to
On 05/05/2014 09:41 PM, Oleg Nesterov wrote:
On 05/05, Denys Vlasenko wrote:
+ * Opcodes we'll probably never support:
+ * 6c-6f - ins,outs. SEGVs if used in userspace
+ * e4-e7 - in,out imm. SEGVs if used in userspace
+ * ec-ef - in,out acc. SEGVs if used in userspace
Well. I have no
Firstly, let me remind that my understanding of low lovel hardware details
is very limited.
On 05/06, Denys Vlasenko wrote:
Oleg, can you clear for me the following -
If the probed instruction triggers an illegal insn or privileged insn
CPU exception - are we completely fine?
Yes I think we
On Mon, 2014-05-05 at 20:24 +0200, Denys Vlasenko wrote:
> After adding these, it's clear we have some awkward choices there.
> Some valid instructions are prohibited from uprobing while
> several invalid ones are allowed.
>
> Hopefully future edits to the good-opcode tables will fix wrong bits
>
On 05/05, Denys Vlasenko wrote:
>
> + * Opcodes we'll probably never support:
> + * 6c-6f - ins,outs. SEGVs if used in userspace
> + * e4-e7 - in,out imm. SEGVs if used in userspace
> + * ec-ef - in,out acc. SEGVs if used in userspace
Well. I have no idea why they are nacked, but this is not the
After adding these, it's clear we have some awkward choices there.
Some valid instructions are prohibited from uprobing while
several invalid ones are allowed.
Hopefully future edits to the good-opcode tables will fix wrong bits
or explain why those bits are not wrong.
No actual code changes.
After adding these, it's clear we have some awkward choices there.
Some valid instructions are prohibited from uprobing while
several invalid ones are allowed.
Hopefully future edits to the good-opcode tables will fix wrong bits
or explain why those bits are not wrong.
No actual code changes.
On 05/05, Denys Vlasenko wrote:
+ * Opcodes we'll probably never support:
+ * 6c-6f - ins,outs. SEGVs if used in userspace
+ * e4-e7 - in,out imm. SEGVs if used in userspace
+ * ec-ef - in,out acc. SEGVs if used in userspace
Well. I have no idea why they are nacked, but this is not the
On Mon, 2014-05-05 at 20:24 +0200, Denys Vlasenko wrote:
After adding these, it's clear we have some awkward choices there.
Some valid instructions are prohibited from uprobing while
several invalid ones are allowed.
Hopefully future edits to the good-opcode tables will fix wrong bits
or
12 matches
Mail list logo
