On Fri, 2018-12-07 at 12:18 +, David Woodhouse wrote:
>
> > #else
> > + struct multicall_space mc = __xen_mc_entry(0);
> > + MULTI_set_segment_base(mc.mc, SEGBASE_GS_USER_SEL, 0);
> > +
> > loadsegment(fs, 0);
> > #endif
>
> That seems to boot and run,
On Thu, 2018-12-06 at 20:27 +, David Woodhouse wrote:
> On Thu, 2018-12-06 at 10:49 -0800, Andy Lutomirski wrote:
> > > On Dec 6, 2018, at 9:36 AM, Andrew Cooper <
> > > andrew.coop...@citrix.com> wrote:
> > > Basically - what is happening is that xen_load_tls() is
> > > invalidating the
> > >
On Thu, 2018-12-06 at 10:49 -0800, Andy Lutomirski wrote:
> > On Dec 6, 2018, at 9:36 AM, Andrew Cooper wrote:
> > Basically - what is happening is that xen_load_tls() is invalidating the
> > %gs selector while %gs is still non-NUL.
> >
> > If this happens to intersect with a vcpu reschedule,
> On Dec 6, 2018, at 9:36 AM, Andrew Cooper wrote:
>
>> On 06/12/2018 17:10, David Woodhouse wrote:
>> On Wed, 2018-11-28 at 08:44 -0800, Andy Lutomirski wrote:
Can we assume it's always from kernel? The Xen code definitely seems to
handle invoking this from both kernel and userspace
On 06/12/2018 17:10, David Woodhouse wrote:
> On Wed, 2018-11-28 at 08:44 -0800, Andy Lutomirski wrote:
>>> Can we assume it's always from kernel? The Xen code definitely seems to
>>> handle invoking this from both kernel and userspace contexts.
>> I learned that my comment here was wrong shortly
On Wed, 2018-11-28 at 08:44 -0800, Andy Lutomirski wrote:
> > Can we assume it's always from kernel? The Xen code definitely seems to
> > handle invoking this from both kernel and userspace contexts.
>
> I learned that my comment here was wrong shortly after the patch landed :(
Turns out the
> On Nov 28, 2018, at 6:56 AM, David Woodhouse wrote:
>
>> On Wed, 2018-08-22 at 09:19 +0200, gre...@linuxfoundation.org wrote:
>> This is a note to let you know that I've just added the patch titled
>>
>>x86/entry/64: Remove %ebx handling from error_entry/exit
>>
>> to the 4.9-stable
On Wed, Nov 28, 2018 at 02:56:32PM +, David Woodhouse wrote:
On Wed, 2018-08-22 at 09:19 +0200, gre...@linuxfoundation.org wrote:
This is a note to let you know that I've just added the patch titled
x86/entry/64: Remove %ebx handling from error_entry/exit
to the 4.9-stable tree which
On Wed, 2018-08-22 at 09:19 +0200, gre...@linuxfoundation.org wrote:
> This is a note to let you know that I've just added the patch titled
>
> x86/entry/64: Remove %ebx handling from error_entry/exit
>
> to the 4.9-stable tree which can be found at:
>
>
On Thu, Aug 16, 2018 at 8:19 AM, Greg KH wrote:
> On Fri, Aug 10, 2018 at 12:23:45AM -0700, Sarah Newman wrote:
>> On 08/09/2018 05:41 AM, David Woodhouse wrote:
>> > On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
>> >> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
>> >>
>> >>
On Fri, Aug 10, 2018 at 12:23:45AM -0700, Sarah Newman wrote:
> On 08/09/2018 05:41 AM, David Woodhouse wrote:
> > On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
> >> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
> >>
> >> This version applies to v4.9.
> >
> > I think you can
On 08/09/2018 05:41 AM, David Woodhouse wrote:
> On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
>> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
>>
>> This version applies to v4.9.
>
> I think you can kill the 'xorl %ebx,%ebx' from error_entry too but yes,
> this does want to
On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
>
> This version applies to v4.9.
I think you can kill the 'xorl %ebx,%ebx' from error_entry too but yes,
this does want to go to 4.9 and earlier because the 'Fixes:' tag is a
bit
On Mon, Jul 23, 2018 at 12:25 AM, Greg KH wrote:
> On Sun, Jul 22, 2018 at 11:05:09AM -0700, Andy Lutomirski wrote:
>> error_entry and error_exit communicate the user vs kernel status of
>> the frame using %ebx. This is unnecessary -- the information is in
>> regs->cs. Just use regs->cs.
>>
>>
On Sun, Jul 22, 2018 at 11:05:09AM -0700, Andy Lutomirski wrote:
> error_entry and error_exit communicate the user vs kernel status of
> the frame using %ebx. This is unnecessary -- the information is in
> regs->cs. Just use regs->cs.
>
> This makes error_entry simpler and makes error_exit more
15 matches
Mail list logo
