We have to do that anyway to deal with 16- and 32-bit userspace return. On May 3, 2014 5:31:41 PM PDT, Andy Lutomirski <l...@amacapital.net> wrote: >On Sat, May 3, 2014 at 4:51 PM, Andy Lutomirski <l...@amacapital.net> >wrote: >> On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin <h...@zytor.com> wrote: >>> On 05/03/2014 04:24 AM, Steven Rostedt wrote: >>>> On Fri, 02 May 2014 21:03:10 -0700 >>>> "H. Peter Anvin" <h...@zytor.com> wrote: >>>> >>>>> >>>>> I'd really like to see a workload which would genuinely benefit >before >>>>> adding more complexity. Now... if we can determine that it >doesn't harm >>>>> anything and would solve the NMI nesting problem cleaner than the >>>>> current solution, that would justify things, too... >>>>> >>>> >>>> As I stated before. It doesn't solve the NMI nesting problem. It >only >>>> handles page faults. We would have to implement this for breakpoint >>>> return paths too. Is that a plan as well? >>>> >>> >>> I would assume we would do it for *ALL* the IRETs. There are only >three >>> IRETs in the kernel last I checked... >> >> I think we should carefully avoid doing it for returns from NMI, >though :) >> >> If you want a realistic benchmark that will speed up, packet >> forwarding might be a good place to look. > >Hmm. I think my patch will blow up with EFI mixed mode if any EFI >functions are called with interrupts enabled. It may also blow up >with when suspending or doing other BIOS things like that. It should >probably check the actual value of CS as opposed to just the CPL. > >I'm not sure what's happening with the alternate GDT in the EFI stuff. > >--Andy
-- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
