search for: 5f310f739b4c

...oris Ostrovsky wrote: >> I know this has been in the tip tree --- when do you think this will go >> Linus tree? In the 4.4 timeframe? > It is queued for 4.5 currently. > >> Xen 32-bit PV guests are broken without this. > So this needs to go into 4.4 or even earlier? Since 5f310f739b4c went > into 4.4, I'd think 4.4 only for this fix too? Yes? Oh, I didn't realize this is scheduled for 4.5. It indeed needs to go into 4.4 because of 5f310f739b4c. Thanks. -boris

...oris Ostrovsky wrote: >> I know this has been in the tip tree --- when do you think this will go >> Linus tree? In the 4.4 timeframe? > It is queued for 4.5 currently. > >> Xen 32-bit PV guests are broken without this. > So this needs to go into 4.4 or even earlier? Since 5f310f739b4c went > into 4.4, I'd think 4.4 only for this fix too? Yes? Oh, I didn't realize this is scheduled for 4.5. It indeed needs to go into 4.4 because of 5f310f739b4c. Thanks. -boris

On 11/19/2015 04:55 PM, Boris Ostrovsky wrote: > After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c > ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up calling xen_iret from xen_sysexit we don't need to fix > up the...

On 11/19/2015 04:55 PM, Boris Ostrovsky wrote: > After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c > ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up calling xen_iret from xen_sysexit we don't need to fix > up the...

On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky <boris.ostrovsky at oracle.com> wrote: > After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c > ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up calling xen_iret from xen_sysexit we don't need to fix > up the...

On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky <boris.ostrovsky at oracle.com> wrote: > After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c > ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up calling xen_iret from xen_sysexit we don't need to fix > up the...

...gmail.com> wrote: > On Wed, Nov 18, 2015 at 3:21 PM, Andy Lutomirski <luto at amacapital.net> wrote: >> On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky >> <boris.ostrovsky at oracle.com> wrote: >>> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c >>> ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack >>> frame that is passed to xen_sysexit is no longer a "standard" one (i.e. >>> it's not pt_regs). >>> >>> Since we end up calling xen_iret from xen_sysex...

...5 at 10:21:37AM -0500, Boris Ostrovsky wrote: > I know this has been in the tip tree --- when do you think this will go > Linus tree? In the 4.4 timeframe? It is queued for 4.5 currently. > Xen 32-bit PV guests are broken without this. So this needs to go into 4.4 or even earlier? Since 5f310f739b4c went into 4.4, I'd think 4.4 only for this fix too? Yes? Thanks. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) --

On Wed, Nov 18, 2015 at 3:21 PM, Andy Lutomirski <luto at amacapital.net> wrote: > On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky > <boris.ostrovsky at oracle.com> wrote: >> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c >> ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack >> frame that is passed to xen_sysexit is no longer a "standard" one (i.e. >> it's not pt_regs). >> >> Since we end up calling xen_iret from xen_sysexit we don't need...

After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack frame that is passed to xen_sysexit is no longer a "standard" one (i.e. it's not pt_regs). Since we end up calling xen_iret from xen_sysexit we don't need to fix up the stack and instead follow entr...

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not used anymore by anyone and so can be removed. v2: * patch both TEST and JZ intructions with a

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not used anymore by anyone and so can be removed. v2: * patch both TEST and JZ intructions with a