Displaying 8 results from an estimated 8 matches for "io_apic_b".
2018 Feb 09
2
retpoline mitigation and 6.0
...fe88
[ 0.000000] At line 412, gsi_base is 0
[ 0.000000] At line 425, gsi_base is -1043715332
[ 0.000000] At line 427, gsi_base is -1043715332
http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/clang
http://david.woodhou.se/clang32.config
http://david.woodhou.se/io_apic_b.i
http://david.woodhou.se/io_apic_b.noretpoline.s
http://david.woodhou.se/io_apic_b.retpoline.s
I don't *think* I screwed up copying and pasting the retpoline thunk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signatur...
2018 Feb 09
0
retpoline mitigation and 6.0
...> [ 0.000000] At line 425, gsi_base is -1043715332
> [ 0.000000] At line 427, gsi_base is -1043715332
>
> http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/ref
> s/heads/clang
> http://david.woodhou.se/clang32.config
>
>
> http://david.woodhou.se/io_apic_b.i
> http://david.woodhou.se/io_apic_b.noretpoline.s
> http://david.woodhou.se/io_apic_b.retpoline.s
>
> I don't *think* I screwed up copying and pasting the retpoline thunk.
So, looking at the retpoline version...
gsi_base is in %edi, and gets spilled to the stack at about .Ltmp2...
2018 Feb 09
3
retpoline mitigation and 6.0
...n't account for the SP adjustment in the
push.
It's weird, because it's basically the opposite of the problem you're
having, which looks like LLVM *is* accounting for the push and is trying to
adjust its offsets accordingly.
Can you send along the full command line used to compile io_apic_b.i?
On Fri, Feb 9, 2018 at 11:38 AM, David Woodhouse <dwmw2 at infradead.org>
wrote:
> On Fri, 2018-02-09 at 11:24 -0800, Reid Kleckner wrote:
> > I haven't read the all the emails in full detail, but it seems pretty
> > clear that __x86_indirect_thunk and __llvm_retpolin...
2018 Feb 09
0
retpoline mitigation and 6.0
On Fri, 2018-02-09 at 08:45 +0000, Chandler Carruth wrote:
> >
> > You're pushing the target (-0x20(%ebp)) onto the stack and then
> > *calling* __x86_indirect_thunk. So it looks like you're expecting
> > __x86_indirect_thunk to do something like
> >
> > call *4(%esp)
> > ret
> >
> > ... except that final 'ret' still
2018 Feb 09
2
retpoline mitigation and 6.0
On Fri, Feb 9, 2018 at 12:26 AM David Woodhouse <dwmw2 at infradead.org> wrote:
>
>
> On Fri, 2018-02-09 at 02:21 +0000, David Woodhouse wrote:
> > On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse wrote:
> > >
> > >
> > > For now I'm just going to attempt to work around it like this in the
> > > kernel, so I can concentrate on the
2018 Feb 09
3
retpoline mitigation and 6.0
..._base is -1043715332
> > [ 0.000000] At line 427, gsi_base is -1043715332
> >
> > http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/ref
> > s/heads/clang
> > http://david.woodhou.se/clang32.config
> >
> >
> > http://david.woodhou.se/io_apic_b.i
> > http://david.woodhou.se/io_apic_b.noretpoline.s
> > http://david.woodhou.se/io_apic_b.retpoline.s
> >
> > I don't *think* I screwed up copying and pasting the retpoline thunk.
>
> So, looking at the retpoline version...
>
> gsi_base is in %edi, and gets...
2018 Feb 19
0
retpoline mitigation and 6.0
...ment in the
> push.
>
> It's weird, because it's basically the opposite of the problem you're
> having, which looks like LLVM *is* accounting for the push and is trying to
> adjust its offsets accordingly.
>
> Can you send along the full command line used to compile io_apic_b.i?
>
> On Fri, Feb 9, 2018 at 11:38 AM, David Woodhouse <dwmw2 at infradead.org>
> wrote:
>>
>> On Fri, 2018-02-09 at 11:24 -0800, Reid Kleckner wrote:
>> > I haven't read the all the emails in full detail, but it seems pretty
>> > clear that __x86_...
2018 Feb 09
0
retpoline mitigation and 6.0
On Fri, 2018-02-09 at 11:24 -0800, Reid Kleckner wrote:
> I haven't read the all the emails in full detail, but it seems pretty
> clear that __x86_indirect_thunk and __llvm_retpoline_push do not do
> the same things. It sounds like __llvm_retpoline_push is equivalent
> to __x86_indirect_thunk except first it swaps the two words on the
> top of the stack.
>
> I arranged