search for: workbase

...gt; so the original 'cli' was replaced with the pv call but to me the offset >>> looks a bit off, no? Shouldn't it always be positive? >> callq takes a 32bit signed displacement, so jumping back by up to 2G is >> perfectly legitimate. > Yes, but > > ostr at workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath > ffffffff817365dd t entry_SYSCALL_64_fastpath > ostr at workbase> nm vmlinux | grep " pv_irq_ops" > ffffffff81c2dbc0 D pv_irq_ops > ostr at workbase> > > so pv_irq_ops.irq_disable is about 5MB ahead of where we are n...

...gt; so the original 'cli' was replaced with the pv call but to me the offset >>> looks a bit off, no? Shouldn't it always be positive? >> callq takes a 32bit signed displacement, so jumping back by up to 2G is >> perfectly legitimate. > Yes, but > > ostr at workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath > ffffffff817365dd t entry_SYSCALL_64_fastpath > ostr at workbase> nm vmlinux | grep " pv_irq_ops" > ffffffff81c2dbc0 D pv_irq_ops > ostr at workbase> > > so pv_irq_ops.irq_disable is about 5MB ahead of where we are n...

...39; was replaced with the pv call but to me the offset > >>> looks a bit off, no? Shouldn't it always be positive? > >> callq takes a 32bit signed displacement, so jumping back by up to 2G is > >> perfectly legitimate. > > Yes, but > > > > ostr at workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath > > ffffffff817365dd t entry_SYSCALL_64_fastpath > > ostr at workbase> nm vmlinux | grep " pv_irq_ops" > > ffffffff81c2dbc0 D pv_irq_ops > > ostr at workbase> > > > > so pv_irq_ops.irq_disable is abo...

On 12/10/17 20:11, Boris Ostrovsky wrote: > On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: >>>> #ifdef CONFIG_PARAVIRT >>>> +/* >>>> + * Paravirt alternatives are applied much earlier than normal alternatives. >>>> + * They are only applied when running on a hypervisor.

On 12/10/17 20:11, Boris Ostrovsky wrote: > On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: >>>> #ifdef CONFIG_PARAVIRT >>>> +/* >>>> + * Paravirt alternatives are applied much earlier than normal alternatives. >>>> + * They are only applied when running on a hypervisor.

...;cli' was replaced with the pv call but to me the offset >>>> looks a bit off, no? Shouldn't it always be positive? >>> callq takes a 32bit signed displacement, so jumping back by up to 2G is >>> perfectly legitimate. >> Yes, but >> >> ostr at workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath >> ffffffff817365dd t entry_SYSCALL_64_fastpath >> ostr at workbase> nm vmlinux | grep " pv_irq_ops" >> ffffffff81c2dbc0 D pv_irq_ops >> ostr at workbase> >> >> so pv_irq_ops.irq_disable is about 5MB...

...ith the pv call but to me the offset >>>>> looks a bit off, no? Shouldn't it always be positive? >>>> callq takes a 32bit signed displacement, so jumping back by up to 2G is >>>> perfectly legitimate. >>> Yes, but >>> >>> ostr at workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath >>> ffffffff817365dd t entry_SYSCALL_64_fastpath >>> ostr at workbase> nm vmlinux | grep " pv_irq_ops" >>> ffffffff81c2dbc0 D pv_irq_ops >>> ostr at workbase> >>> >>> so pv_irq_ops....

...l >> >> >> so the original 'cli' was replaced with the pv call but to me the offset >> looks a bit off, no? Shouldn't it always be positive? > callq takes a 32bit signed displacement, so jumping back by up to 2G is > perfectly legitimate. Yes, but ostr at workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath ffffffff817365dd t entry_SYSCALL_64_fastpath ostr at workbase> nm vmlinux | grep " pv_irq_ops" ffffffff81c2dbc0 D pv_irq_ops ostr at workbase> so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I didn't mean that x...

...offset > >>>>> looks a bit off, no? Shouldn't it always be positive? > >>>> callq takes a 32bit signed displacement, so jumping back by up to 2G is > >>>> perfectly legitimate. > >>> Yes, but > >>> > >>> ostr at workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath > >>> ffffffff817365dd t entry_SYSCALL_64_fastpath > >>> ostr at workbase> nm vmlinux | grep " pv_irq_ops" > >>> ffffffff81c2dbc0 D pv_irq_ops > >>> ostr at workbase> > >>> &g...

...offset > >>>>> looks a bit off, no? Shouldn't it always be positive? > >>>> callq takes a 32bit signed displacement, so jumping back by up to 2G is > >>>> perfectly legitimate. > >>> Yes, but > >>> > >>> ostr at workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath > >>> ffffffff817365dd t entry_SYSCALL_64_fastpath > >>> ostr at workbase> nm vmlinux | grep " pv_irq_ops" > >>> ffffffff81c2dbc0 D pv_irq_ops > >>> ostr at workbase> > >>> &g...